x/net/dns/dnsmessage: SOA RNAME might contain dots inside labels

[mateusz834]

It seems like there exist in a wild domain names that contains dots inside of labels, we reject them in the dnsmessage parser since we have no way to represent them in the Name struct, see #56246.

$ dig gc.ca SOA +noall +answer
gc.ca.			86400	IN	SOA	ns10.ent.global.gc.ca. ssc\.enterpriseddi-entreprise\.spc.ssc-spc.gc.ca. 2025102304 10800 3600 604800 3600
$ dig washingtonpost.com SOA +noall +answer
washingtonpost.com.	900	IN	SOA	sdns34.ultradns.com. admin\.contact.digitalink.com. 2016123863 3600 900 2592000 300

DNS spec requires that '@' of an email becomes '.' (label separator), but the local-part can also contains dots. Meaning that foo.bar@example.com becomes foo\.bar.example.com.

Originally reported at golang/net#154 (comment)

I think the only solution might be a v2, unless there is a way to make the Name struct contain the encoded DNS form instead.

CC @fortuna

[gabyhelp]

Related Issues

• x/net/dns: invalid assumptions about domain names and character strings #24288
• x/net/dnsmessage: dots inside dns name label should be considered invalid #56246 (closed)
• net: mishandling of dotted labels in domain names #10631 (closed)
• net: isDomainName rejects valid domains #17659
• net: domain name length checks should use wire format #17549 (closed)
• net: packDomainName encodes "." as "\0\0" instead of "\0" #14372 (closed)

Related Code Changes

• net: recognize non-LDH domain names as valid per RFC 1035

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[fortuna]

Perhaps the parser could have an option "output raw names" that outputs Name with the binary format instead. This way we can represent any name. Perhaps we add a convenience Name.Labels() [][]byte or []string for convenience.

[mknyszek]

CC @neild

[fortuna]

I used AI to implement my proposal. Please take a look and let me know what you think.

Changes:

• Added Name.IsRaw to indicate whether Name.Data is in raw or presentation format.
• Added Parser.EnableRawNames() to output raw names instead. This resulted in having to wire a raw boolean throughout the parsing code.

This is not implemented, but I would like to discuss make the regular flow ("raw" not enabled) do its best effort in parsing names with dots and other bytes that need escaping, putting the escaped presentation format in Name.Data. It should only fail if the presentation format would overflow the array. I believe that's the best functionality for the existing API, but there could be consequences. It should be on a separate change.