Le 15/01/2025 à 17:12, Lee a écrit :
On Wed, Jan 15, 2025 at 5:41 AM Emmanuel Fusté wrote:
Le 15/01/2025 à 05:59, Nick Tait via bind-users a écrit :
On 15/01/2025 10:47, Emmanuel Fusté wrote:
If so, does the ISC ship a db.local with a wildcard - eg.
--- cut here ---
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA ::1
* IN A 127.0.0.1
IN AAAA ::1
--- cut here ---
to answer for any .localhost name?
Don't please. See RFC6761
From RFC 6761:
6.3. Domain Name Reservation Considerations for "localhost."
The domain "localhost." *and any names falling within
".localhost."*
are special in the following ways:
...
4. Caching DNS servers SHOULD recognize localhost names as special
and SHOULD NOT attempt to look up NS records for them, or
otherwise query authoritative DNS servers in an attempt to
resolve localhost names. Instead, caching DNS servers SHOULD,
for all such address queries, generate an immediate positive
response giving the IP loopback address, and for all other
query
types, generate an immediate negative response. This is to
avoid
unnecessary load on the root name servers and other name
servers.
5. Authoritative DNS servers SHOULD recognize localhost names as
special and handle them as described above for caching DNS
servers.
To me this seems like a pretty clear endorsement for inclusion of the
wildcard entry "*.localhost." in db.local?
Nick.
I think we should avoid opening the Pandora's box with *.localhost.
The "avoid unnecessary load on the root name servers and other name
servers" goal is already reached without it.
Any names under .localhost are nonsense even if not prohibited/allowed
by the RFC.
It fix/deserve nothing. In an ideal world, localhost would be in the
bind default empty-zone list, and localhost hierarchy handled at the
upper layer by the resolver libs/apis, not the servers.
And as personal biased opinion : DNS wildcards are evil and should have
not existed in the first place. So I prefer to avoid them anyway.
But you could disagree.
I think maintaining RFC compliance is a Good Thing :) Not just the
required parts but the SHOULD and SHOULD NOTs and even the MAY and MAY
NOTs.
It seems you disagree about following all of the SHOULDs in RFC 6761 -
but are there any reasons other than personal bias for not following
the recommendation?
Yes, the first paragraph of my answer.
Obviously you're free to do whatever you like on your network, but my
question is about which behavior is more correct wrt RFC 6761. It
still seems to me that responding with a localhost address for names
falling within ".localhost." is the right thing to do.
Be compliant an the right level (local resolver/API) otherwise you will
set it in stone and make an already bad situation worse.
In the RFC context, "localhost." domain and complete hierarchy globally
called "localhost names". The objective of the rfc is "to avoid
unnecessary load on the root name servers and other name servers".
Specifying the response (127.0.0.1, ::1) is going to far in my opinion,
it is only a good advice to not break the myriad of broken software
(global policy). My preferred option is an empty zone to break and force
fixing bad configurations/broken software (local policy).
It does not prevent any special local policy/use regarding the
"localhost." domain/hierarchy.
Your more correct behavior wrt RFC 6761 will make valid more bad
configurations/broken software which are rejected forever, without any
benefits. It should/must not (in my opinion) be a default configuration
in a delivered DNS server package.
My reasoning is wrong if you think that such requests may/should/must
legitimately reach autoritatives or caching DNS servers in any situation
(by default/global policy).
Best regards,
Emmanuel.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
