[GH-ISSUE #2932] fqdn vs non-fqdn name comparison difference between 0.24 vs 0.25 #1092

New issue

Closed

opened 2026-03-16 01:35:27 +03:00 by kerem · 2 comments

kerem commented

2026-03-16 01:35:27 +03:00

Owner

Originally created by @pronebird on GitHub (Apr 15, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2932

Hi,

Consider the following piece of code:

let my_domains = vec![
  LowerName::from(Name::from_str("example.com").unwrap()))
];

let query: LowerQuery = // obtained from resolver
let query_name = query.name(); // example.com.
my_domains.contains(query.name()) // true in v0.24, false in v0.25

The difference between v0.24 and v0.25 is that my_domains.contains(query.name()) now returns false because fully qualified name no longer matches non-fully qualified I presume.

Issues like these are nightmare to resolve, I wish we had some tools in place to warn developers of such changes.

What's the best way to handle this?

p.s: I suppose it's safer for me to stick to checking against the fully-qualified domain names since Request are likely carrying them at all times? For the context I am crafting my own responses for certain domains and therefore handling requests manually.

Originally created by @pronebird on GitHub (Apr 15, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2932 Hi, Consider the following piece of code: ```rs let my_domains = vec![ LowerName::from(Name::from_str("example.com").unwrap())) ]; let query: LowerQuery = // obtained from resolver let query_name = query.name(); // example.com. my_domains.contains(query.name()) // true in v0.24, false in v0.25 ``` The difference between v0.24 and v0.25 is that `my_domains.contains(query.name())` now returns `false` because fully qualified name no longer matches non-fully qualified I presume. Issues like these are nightmare to resolve, I wish we had some tools in place to warn developers of such changes. What's the best way to handle this? p.s: I suppose it's safer for me to stick to checking against the fully-qualified domain names since `Request` are likely carrying them at all times? For the context I am crafting my own responses for certain domains and therefore handling requests manually.

kerem closed this issue

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

kerem commented

2026-03-16 01:35:38 +03:00

Author

Owner

@djc commented on GitHub (Apr 15, 2025):

It is indeed painful and there is no straightforward way to find out where this is an issue. This is why we highlighted it in the release notes. If you can describe at a high-level what your application is like, we might be able to give you some guidance.

It is indeed true that messages always contain fully-qualified names so if you're comparing to a name from a message you should take that into account.

@djc commented on GitHub (Apr 15, 2025): It is indeed painful and there is no straightforward way to find out where this is an issue. This is why we highlighted it in the release notes. If you can describe at a high-level what your application is like, we might be able to give you some guidance. It is indeed true that messages always contain fully-qualified names so if you're comparing to a name from a message you should take that into account.

kerem commented

2026-03-16 01:35:43 +03:00

Author

Owner

@pronebird commented on GitHub (Apr 15, 2025):

It is indeed painful and there is no straightforward way to find out where this is an issue. This is why we highlighted it in the release notes. If you can describe at a high-level what your application is like, we might be able to give you some guidance.

It is indeed true that messages always contain fully-qualified names so if you're comparing to a name from a message you should take that into account.

Oh I must have missed that in the notes. My bad.

I am capturing dns and crafting custom responses with static IPs for certain domains. The check that verifies whether the request should be overriden stopped matching against non-fqnd names. So I just made sure those all always fully qualified and then everything is back in order.

Thanks for guidance.

@pronebird commented on GitHub (Apr 15, 2025): > It is indeed painful and there is no straightforward way to find out where this is an issue. This is why we highlighted it in the release notes. If you can describe at a high-level what your application is like, we might be able to give you some guidance. > > It is indeed true that messages always contain fully-qualified names so if you're comparing to a name from a message you should take that into account. Oh I must have missed that in the notes. My bad. I am capturing dns and crafting custom responses with static IPs for certain domains. The check that verifies whether the request should be overriden stopped matching against non-fqnd names. So I just made sure those all always fully qualified and then everything is back in order. Thanks for guidance.

kerem referenced this issue

2026-03-16 04:17:45 +03:00

[PR #1092] [CLOSED] Bump thiserror from 1.0.15 to 1.0.16 #1961