[GH-ISSUE #821] Name and Label parsing still to restrictive, allow \" #546

New issue

Open

opened 2026-03-15 23:05:32 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:05:32 +03:00

Owner

Originally created by @bluejekyll on GitHub (Jul 1, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/821

Currently " is not accepted in Label parsing.

In this funtion:

https://github.com/bluejekyll/trust-dns/blob/master/crates/proto/src/rr/domain/label.rs#L215

We should 1) better document what these flags do. 2) perhaps change the default match case _ to be the same as ., where when it's being encoded it must be escaped.

Consider refactoring that function to rather than taking booleans, return an enum that represents if the character needs to be encoded, and or is safe/not-safe in standard names.

Originally created by @bluejekyll on GitHub (Jul 1, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/821 Currently \" is not accepted in Label parsing. In this funtion: https://github.com/bluejekyll/trust-dns/blob/master/crates/proto/src/rr/domain/label.rs#L215 We should 1) better document what these flags do. 2) perhaps change the default match case `_` to be the same as `.`, where when it's being encoded it must be escaped. Consider refactoring that function to rather than taking booleans, return an enum that represents if the character needs to be encoded, and or is safe/not-safe in standard names.

kerem added the

bug

easy

labels

2026-03-15 23:05:32 +03:00

kerem commented

2026-03-15 23:05:44 +03:00

Author

Owner

@ppentchev commented on GitHub (Jun 12, 2022):

Hi,

First of all, thanks a lot for writing and maintaining the trust-dns suite! It is very useful and very well-designed.

I'm not sure if what I am asking is really a good idea, but I tried implementing a simple client for the https://www.dns.toys/ API and it was all fine and good right up to the point where the API requires the use of a slash as a delimiter between the city name and the two-letter country code. You can probably see where this is going: Name::from_str() simply refuses to allow me to do that :)

Yes, I have pretty much grown up with the DNS RFCs, I actually remember people complaining about 2600.com back in the nineties, and I have filed tickets with ISPs for using slashes in the names of their routers, breaking my too-strict-for-my-own-good diagnostic tools. So... yeah. I don't know if it is a good idea, and if you feel that "nah, please go talk to the dns.toys maintainers, let them fix their API" is the proper response, I will accept it. Still, I thought I'd ask :)

Thanks again, and keep up the great work!

G'luck,
Peter

@ppentchev commented on GitHub (Jun 12, 2022): Hi, First of all, thanks a lot for writing and maintaining the trust-dns suite! It is very useful and very well-designed. I'm not sure if what I am asking is really a good idea, but I tried implementing a simple client for the https://www.dns.toys/ API and it was all fine and good right up to the point where the API requires the use of a slash as a delimiter between the city name and the two-letter country code. You can probably see where this is going: `Name::from_str()` simply refuses to allow me to do that :) Yes, I have pretty much grown up with the DNS RFCs, I actually remember people complaining about 2600.com back in the nineties, and I have filed tickets with ISPs for using slashes in the names of their routers, breaking my too-strict-for-my-own-good diagnostic tools. So... yeah. I don't know if it is a good idea, and if you feel that "nah, please go talk to the dns.toys maintainers, let them fix their API" is the proper response, I will accept it. Still, I thought I'd ask :) Thanks again, and keep up the great work! G'luck, Peter

kerem commented

2026-03-15 23:05:49 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 12, 2022):

Those are some interesting examples, I believe this is the one you're talking about? dig paris/fr.time @dns.toys

I've been tempted in the past to remove a lot of the restrictions we have on the names that we parse, this is a good example. We could easily allow this here: https://github.com/bluejekyll/trust-dns/blob/main/crates/proto/src/rr/domain/label.rs#L225

I'm not familiar with that usage, but I don't seen an explicit reason for disallowing /, especially if it's in common usage like this.

@bluejekyll commented on GitHub (Jun 12, 2022): Those are some interesting examples, I believe this is the one you're talking about? `dig paris/fr.time @dns.toys` I've been tempted in the past to remove a lot of the restrictions we have on the names that we parse, this is a good example. We could easily allow this here: https://github.com/bluejekyll/trust-dns/blob/main/crates/proto/src/rr/domain/label.rs#L225 I'm not familiar with that usage, but I don't seen an explicit reason for disallowing `/`, especially if it's in common usage like this.

kerem commented

2026-03-15 23:05:54 +03:00

Author

Owner

@ppentchev commented on GitHub (Jun 14, 2022):

Hi,

Thanks for the quick answer, and sorry it took me a while to reply. So, hm. Yeah, I could try to whip up a simple patch to allow some specific characters (a slash? what else?) if that's what you think is right. Or, if you want, I could try to do something in the direction of your original message here - allow everything, but escape it as necessary. Or, on the gripping hand, I could try to make something a bit more complex, like a builder pattern - there would probably have to be one for labels and also one for names that either copies most of the options or knows how to use a label builder.

So... which of these three ways would you prefer? Or is it more like "none of the above"? :)

G'luck,
Peter

@ppentchev commented on GitHub (Jun 14, 2022): Hi, Thanks for the quick answer, and sorry it took me a while to reply. So, hm. Yeah, I could try to whip up a simple patch to allow some specific characters (a slash? what else?) if that's what you think is right. Or, if you want, I could try to do something in the direction of your original message here - allow everything, but escape it as necessary. Or, on the gripping hand, I could try to make something a bit more complex, like a builder pattern - there would probably have to be one for labels and also one for names that either copies most of the options or knows how to use a label builder. So... which of these three ways would you prefer? Or is it more like "none of the above"? :) G'luck, Peter

kerem referenced this issue

2026-03-16 02:10:50 +03:00

[PR #566] [MERGED] Delays all connections until actual use. #1519