starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #2452] Handling of full stops in labels #993

New issue

Open

opened 2026-03-16 01:12:23 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 01:12:23 +03:00

Owner

Originally created by @divergentdave on GitHub (Sep 12, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2452

This issue is following up on previous discussions in #2419 and #2433. Currently, IDNA labels that include a full stop do not get encoded as UTF-8 correctly, because full stops are unescaped. (ASCII labels do have full stops escaped correctly when they are encoded) If a domain name is built from these strings later, then the internal full stops will get interpreted as separating labels, rather than being part of a label.

I previously found that full stops inside labels were primarily used for representing email addresses as domain names, for use with various now-defunct resource record types. Unfortunately, that's not the whole story. The SOA record's RNAME field is a mailbox represented as a domain name in this same way. (dig SOA google.com prints dns-admin.google.com, which represents the email dns-admin@google.com. Twitter is the exception that proves the rule, because their SOA lists noc\@twitter.com.) I did some digging to see if this could be a practical problem, and found a potentially affected zone by searching through a public dataset of DNS packet captures. dig SOA adadvisor.net includes a full stop in the local part of the email address (escaped with a backslash when printed by dig).

Thus, I don't think it would be practical to simply disallow full stops in labels. The SOA struct uses Name to represent the RNAME field currently. Any lookup inside the adadvisor.net zone, or any similarly affected zone, which triggers an SOA record in the authority section of the response, would fail when trying to parse this field.

I believe the two main options at this point are to still allow full stops in Label/Name, fixing the encoding and any other related bugs, or to have two separate types for names that do and don't allow full stops in labels, and switch the rname field to the former.

Originally created by @divergentdave on GitHub (Sep 12, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2452 This issue is following up on previous discussions in #2419 and #2433. Currently, IDNA labels that include a full stop do not get encoded as UTF-8 correctly, because full stops are unescaped. (ASCII labels do have full stops escaped correctly when they are encoded) If a domain name is built from these strings later, then the internal full stops will get interpreted as separating labels, rather than being part of a label. I previously found that full stops inside labels were primarily used for representing email addresses as domain names, for use with various now-defunct resource record types. Unfortunately, that's not the whole story. The SOA record's RNAME field is a mailbox represented as a domain name in this same way. (`dig SOA google.com` prints `dns-admin.google.com`, which represents the email `dns-admin@google.com`. Twitter is the exception that proves the rule, because their SOA lists `noc\@twitter.com`.) I did some digging to see if this could be a practical problem, and found a potentially affected zone by searching through a public dataset of DNS packet captures. `dig SOA adadvisor.net` includes a full stop in the local part of the email address (escaped with a backslash when printed by `dig`). Thus, I don't think it would be practical to simply disallow full stops in labels. The `SOA` struct uses `Name` to represent the `RNAME` field currently. Any lookup inside the `adadvisor.net` zone, or any similarly affected zone, which triggers an `SOA` record in the authority section of the response, would fail when trying to parse this field. I believe the two main options at this point are to still allow full stops in `Label`/`Name`, fixing the encoding and any other related bugs, or to have two separate types for names that do and don't allow full stops in labels, and switch the `rname` field to the former.

kerem added the

crate:proto

compliance

labels

2026-03-16 01:12:23 +03:00

kerem commented

2026-03-16 01:12:33 +03:00

Author

Owner

@djc commented on GitHub (Sep 12, 2024):

Thanks for digging deeper on this!

I believe the two main options at this point are to still allow full stops in Label/Name, fixing the encoding and any other related bugs, or to have two separate types for names that do and don't allow full stops in labels, and switch the rname field to the former.

Which of these two do you think we should pick? Do you have a preference, and why? On the face of it, I like the latter option of having a different type for holding the rname, assuming we can get away with not having too much extra complexity for it. (But since I don't think we have any further interpreting of that field's constants, it seems okay?)

(I'm a little confused by the use of "full stop" instead of maybe "period" -- is there a reason to use that terminology?)

@djc commented on GitHub (Sep 12, 2024): Thanks for digging deeper on this! > I believe the two main options at this point are to still allow full stops in `Label`/`Name`, fixing the encoding and any other related bugs, or to have two separate types for names that do and don't allow full stops in labels, and switch the `rname` field to the former. Which of these two do you think we should pick? Do you have a preference, and why? On the face of it, I like the latter option of having a different type for holding the `rname`, assuming we can get away with not having too much extra complexity for it. (But since I don't think we have any further interpreting of that field's constants, it seems okay?) (I'm a little confused by the use of "full stop" instead of maybe "period" -- is there a reason to use that terminology?)

kerem commented

2026-03-16 01:12:39 +03:00

Author

Owner

@divergentdave commented on GitHub (Sep 13, 2024):

I think I prefer keeping one set of label/name types. The RNAME field can use the same domain name compression as many other domain name fields, so we do need to parse it. Domain name handling logic is a lot of complexity as it is, so I'm loathe to duplicate it; if we have to get email encoding "right" once, we may as well use it for all domain names.

(I'm a little confused by the use of "full stop" instead of maybe "period" -- is there a reason to use that terminology?)

I picked this up from staring at UTS #46, as that's the Unicode name of U+002E, but yeah, same thing.

@divergentdave commented on GitHub (Sep 13, 2024): I think I prefer keeping one set of label/name types. The `RNAME` field can use the same domain name compression as many other domain name fields, so we do need to parse it. Domain name handling logic is a lot of complexity as it is, so I'm loathe to duplicate it; if we have to get email encoding "right" once, we may as well use it for all domain names. > (I'm a little confused by the use of "full stop" instead of maybe "period" -- is there a reason to use that terminology?) I picked this up from staring at UTS #46, as that's the Unicode name of U+002E, but yeah, same thing.

kerem commented

2026-03-16 01:12:44 +03:00

Author

Owner

@djc commented on GitHub (Sep 16, 2024):

I think I prefer keeping one set of label/name types. The RNAME field can use the same domain name compression as many other domain name fields, so we do need to parse it. Domain name handling logic is a lot of complexity as it is, so I'm loathe to duplicate it; if we have to get email encoding "right" once, we may as well use it for all domain names.

Alright, I think your reasoning makes sense. @marcus0x62 opinions?

@djc commented on GitHub (Sep 16, 2024): > I think I prefer keeping one set of label/name types. The `RNAME` field can use the same domain name compression as many other domain name fields, so we do need to parse it. Domain name handling logic is a lot of complexity as it is, so I'm loathe to duplicate it; if we have to get email encoding "right" once, we may as well use it for all domain names. Alright, I think your reasoning makes sense. @marcus0x62 opinions?

kerem commented

2026-03-16 01:12:49 +03:00

Author

Owner

@marcus0x62 commented on GitHub (Sep 17, 2024):

I think it makes sense to implement this in Name -- we already have Name and LowerName, and while I guess we could add an "UnrestrictedName" or something, that seems like more trouble than it is worth. There are already many situations where the difference in helper methods between the two name types is inconvenient.

We could add helper methods for constructing new names to guarantee a name has only the "preferred" characters from RFC1035 where that is desired and/or to detect if a name has non-preferred characters.

@marcus0x62 commented on GitHub (Sep 17, 2024): I think it makes sense to implement this in Name -- we already have Name and LowerName, and while I guess we could add an "UnrestrictedName" or something, that seems like more trouble than it is worth. There are already many situations where the difference in helper methods between the two name types is inconvenient. We could add helper methods for constructing new names to guarantee a name has only the "preferred" characters from RFC1035 where that is desired and/or to detect if a name has non-preferred characters.

kerem referenced this issue

2026-03-16 02:29:11 +03:00

[PR #993] [MERGED] [trust-dns-resolver] update the proto dependency #1843