technically dns is 8-bit clean, and \n is sort of a valid character in a dns name, so this corner case must be dealt with in the zone parser and not here

@miekg after some dig into the parser code, it seems impossible to deal this case in the zone parser.

Because all the rr depends on the toAbsoluteName() need to deal this case. But different rr has different rdata format.

For example,

• the CNAME has the rdata format of example.org.
• the MX has the rdata format of 50 mail
• the SVR has the rdata format of 0 5 5060 sipserver.example.com.
• the HTTPS has the rdata format of HTTPS 1 . port=8002

You cannot detect the bad target without knowing the rdata format.

Fortunately, all target in the rdata need to use the toAbsoluteName() method to uniform the domain. It's seems appropriate to add the check logic in the toAbsoluteName() method.

Indeed, but it may be possible to detect "no data" seen when a comment token appears? It's not the newline you care about but the fact nothing is specified until you see a comment token.

Don't know if that's easy to do or not, but somewhere in that area you have to look for a solution

the fact nothing is specified until you see a comment token.

This is only true for the CNAME case. For the rr with rdate containing both target and other information like MX or SVR, it fails.

For example, in bad.example.org. MX 10 ; bad mx, the target is after the priority of 10. If we want to deal this case, it seems we need to add some logic in the case zExpectRdata: branch. However, in the MX example, its rdata is not empty, but still invalid. The parser main loop cannot detect the invalid target because it does not know the rdata format.

If checking target is not accepted in the toAbsoluteName() method, it seems no choose by do the validation in the parse() method of every related rr separately. There are more that 30 different rr types need to be updated.