starred/hickory-dns

Fork 0

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

[GH-ISSUE #332] rfc6761: Add `.localhost.`, `.invalid` and reverse mapping validation for server #152

New issue

Open

opened 2026-03-07 22:29:01 +03:00 by kerem · 9 comments

kerem commented

2026-03-07 22:29:01 +03:00

Owner

Originally created by @bluejekyll on GitHub (Jan 26, 2018).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/332

see client/src/rr/zone.rs and ZoneUsage for matching zone names.

Originally created by @bluejekyll on GitHub (Jan 26, 2018). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/332 see `client/src/rr/zone.rs` and `ZoneUsage` for matching zone names.

kerem added the

enhance

crate:server

labels

2026-03-07 22:29:01 +03:00

kerem commented

2026-03-07 22:29:12 +03:00

Author

Owner

@DemiMarie commented on GitHub (Mar 18, 2018):

I will take this.

@DemiMarie commented on GitHub (Mar 18, 2018): I will take this.

kerem commented

2026-03-07 22:29:17 +03:00

Author

Owner

@DemiMarie commented on GitHub (Apr 4, 2018):

I think I can handle the .localhost and .invalid parts.

@DemiMarie commented on GitHub (Apr 4, 2018): I think I can handle the `.localhost` and `.invalid` parts.

kerem commented

2026-03-07 22:29:22 +03:00

Author

Owner

@DemiMarie commented on GitHub (Apr 4, 2018):

So this seems like a simple problem of substring matching. For .invalid, we can simply ignore it at the loading stage (causing the server to return failure by default). For .localhost, we can just add a pinned entry.

@DemiMarie commented on GitHub (Apr 4, 2018): So this seems like a simple problem of substring matching. For `.invalid`, we can simply ignore it at the loading stage (causing the server to return failure by default). For `.localhost`, we can just add a pinned entry.

kerem commented

2026-03-07 22:29:27 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 4, 2018):

Take a look at this module: https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/usage.rs

I think that is what we probably want... the is_zone_of function does the proper domain checking...

@bluejekyll commented on GitHub (Apr 4, 2018): Take a look at this module: `https://github.com/bluejekyll/trust-dns/blob/master/proto/src/rr/domain/usage.rs` I think that is what we probably want... the `is_zone_of` function does the proper domain checking...

kerem commented

2026-03-07 22:29:32 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 4, 2018):

The real question in my mind is where we actually perform this check... What I think would be neat is to start a zone validation component, that would check that zones are good to load and serve. I could see this as part of that. Then there is the actual resolution, i.e. returning standard entries for this stuff. For that the question in my mind is, should we just have standard zone files that are loaded (potentially allowing people to change the functionality) or should these be hardcoded entries in the authority...

@bluejekyll commented on GitHub (Apr 4, 2018): The real question in my mind is where we actually perform this check... What I think would be neat is to start a zone validation component, that would check that zones are good to load and serve. I could see this as part of that. Then there is the actual resolution, i.e. returning standard entries for this stuff. For that the question in my mind is, should we just have standard zone files that are loaded (potentially allowing people to change the functionality) or should these be hardcoded entries in the authority...

kerem commented

2026-03-07 22:29:37 +03:00

Author

Owner

@DemiMarie commented on GitHub (Apr 4, 2018):

I think we should never pass a request upstream when the RFC prohibits us
from doing so, but I could see uses for allowing local configuration to
override the values we return. This should be opt-in though, perhaps with
a command-line switch. The default should be standards-conforming behavior.

On Wed, Apr 4, 2018, 1:05 PM Benjamin Fry notifications@github.com wrote:

The real question in my mind is where we actually perform this check...
What I think would be neat is to start a zone validation component, that
would check that zones are good to load and serve. I could see this as part
of that. Then there is the actual resolution, i.e. returning standard
entries for this stuff. For that the question in my mind is, should we just
have standard zone files that are loaded (potentially allowing people to
change the functionality) or should these be hardcoded entries in the
authority...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bluejekyll/trust-dns/issues/332#issuecomment-378673584,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGGWB-Cfd6flJ_cvhVEsO6LEZuPgQVC4ks5tlP1HgaJpZM4Rt4bA
.

@DemiMarie commented on GitHub (Apr 4, 2018): I think we should never pass a request upstream when the RFC prohibits us from doing so, but I could see uses for allowing local configuration to override the values we return. This should be opt-in though, perhaps with a command-line switch. The default should be standards-conforming behavior. On Wed, Apr 4, 2018, 1:05 PM Benjamin Fry <notifications@github.com> wrote: > The real question in my mind is where we actually perform this check... > What I think would be neat is to start a zone validation component, that > would check that zones are good to load and serve. I could see this as part > of that. Then there is the actual resolution, i.e. returning standard > entries for this stuff. For that the question in my mind is, should we just > have standard zone files that are loaded (potentially allowing people to > change the functionality) or should these be hardcoded entries in the > authority... > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/bluejekyll/trust-dns/issues/332#issuecomment-378673584>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGGWB-Cfd6flJ_cvhVEsO6LEZuPgQVC4ks5tlP1HgaJpZM4Rt4bA> > . >

kerem commented

2026-03-07 22:29:42 +03:00

Author

Owner

@DemiMarie commented on GitHub (Apr 6, 2018):

Also note that .onion domains are reserved for Tor hidden services and shall not be successfully resolved otherwise.

@DemiMarie commented on GitHub (Apr 6, 2018): Also note that `.onion` domains are reserved for Tor hidden services and shall not be successfully resolved otherwise.

kerem commented

2026-03-07 22:29:48 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 6, 2018):

We can add that, though I don't know if it's RFC compliant. It would also be interesting to talk about .onion resolution at some point.

@bluejekyll commented on GitHub (Apr 6, 2018): We can add that, though I don't know if it's RFC compliant. It would also be interesting to talk about `.onion` resolution at some point.

kerem commented

2026-03-07 22:29:53 +03:00

Author

Owner

@moonshiner commented on GitHub (Apr 10, 2018):

RFC 7686 added .onion to the special use registry.

@moonshiner commented on GitHub (Apr 10, 2018): RFC 7686 added .onion to the special use registry.

kerem referenced this issue

2026-03-15 22:10:52 +03:00

[GH-ISSUE #152] NSEC validation failing in nightly #368