localhost name lookup

[Emmanuel Fusté]

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.