Looking at a Rocky9 box...
ping localhost
ping squirrel.localhost
ping curl.localhost

all resolve to 127.0.0.1.  Avg response .043-.047ms for each.  Pinging another 
ip is like 10-20 times slower.
The localhosts file contains:

127.0.0.1   localhost  localhost.localdomain localhost4 localhost4.localdomain4
::1                     localhost   localhost.localdomain localhost6 
localhost6.localdomain6

I don't know if that is unique to the redhat line of systems - or version 9.  
It seems to have wildcard built in.


RW

________________________________
From: Lee <ler...@gmail.com>
Sent: Tuesday, January 14, 2025 10:48 AM
To: Robert Wagner <rwag...@tesla.net>
Cc: bind-users@lists.isc.org <bind-users@lists.isc.org>
Subject: Re: localhost name lookup

This email originated from outside of TESLA

Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Tue, Jan 14, 2025 at 6:56 AM Robert Wagner wrote:
>
> All,
> I wanted to better understand the use-case of having a DNS server provide 
> localhost lookup. I think every OS has a hosts file with localhost set for 
> 127.0.0.1. This is an instantaneous resolution for localhost, rather than 
> going through the process of setting of a network connection or worse (TCP 
> socket with TLS).
> Offhand, having a DNS server resolve this seems like unnecessary traffic.

Yes, it is.  But it happens sometimes.  What does your machine do with
a "ping zippy.localhost" ?

> I would be interested in the timing difference between having curl.localhost 
> in the hosts file versus your DNS server.
> This may also allow your localhost resolution and services to continue should 
> something prevent you from reaching the DNS server (or network delays) - thus 
> improving uptime.

I don't care about how long it takes .. all that much :)  I'm more
concerned with Doing The Right Thing and answering with a localhost
address for foo.bar.bax.localhost seems to be the right thing to do
(and isn't possible in the general case for /etc/hosts - or does it
allow wildcards now?)

The question came up here:
https://lists.privoxy.org/pipermail/privoxy-devel/2025-January/000801.html

It'd be nice to avoid things like

= > On my systems hostnames ending in .localhost resolve to 127.0.0.1 and ::1.
=
= On my system this isn't the case.  I first had to install
= systemd-resolved and point DNS to 127.0.0.53 instead of using the
= locally installed bind on 127.0.0.1.

Thanks
Lee


> ________________________________
> From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Eric 
> <e...@digitalert.net>
> Sent: Sunday, January 12, 2025 9:39 PM
> To: Lee <ler...@gmail.com>
> Cc: bind-users@lists.isc.org <bind-users@lists.isc.org>
> Subject: Re: localhost name lookup
>
> This email originated from outside of TESLA
>
> Do not click links or open attachments unless you recognize the sender and 
> know the content is safe.
>
> I did, but my thought would be it's up to the dns admin to define those zone 
> configurations as you have done. I may be wrong though.
>
>
>
> Jan 12, 2025 6:36:03 PM Lee <ler...@gmail.com>:
>
> > On Sun, Jan 12, 2025 at 5:15 PM Eric wrote:
> >>
> >> That is means that the 'domain' is reserved and can be used locally. It 
> >> doesn't specify all records in that namespace / domain will resolve to 
> >> 127.0.01.
> >>
> >> Think of it like .com
> >>
> >> If you want every A record in *.localhost to resolve to 127.0.0.1 what you 
> >> did will do that.
> >
> > Did you look at the RFC?
> >
> >    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...
> >
> >    5.  Authoritative DNS servers SHOULD recognize localhost names as
> >        special and handle them as described above for caching DNS
> >        servers.
> >
> > So OK.. SHOULD isn't the same as MUST so bind as configured isn't
> > violating that RFC.  But is there a _good_ reason to not follow the
> > SHOULD recommendation?
> >
> > Thanks,
> > Lee
> >
> >>
> >> Jan 12, 2025 4:38:09 PM Lee:
> >>
> >>> Excuse my ignorance, but
> >>>
> >>> https://datatracker.ietf.org/doc/html/rfc6761#section-6.3
> >>>
> >>>    The domain "localhost." and any names falling within ".localhost."
> >>>    are special in the following ways:
> >>>
> >>> sure seems to mean that if I lookup curlmachine.localhost I should get
> >>> a 127.0.0.1 or ::1 address returned.  Correct?
> >>>
> >>> I had to change my db.local file to
> >>>
> >>> $ cat db.local
> >>> ;
> >>> ; BIND data file for local loopback interface
> >>> ;
> >>> $TTL    604800
> >>> @       IN      SOA     localhost. root.localhost. (
> >>>                               3         ; Serial
> >>>                          604800         ; Refresh
> >>>                           86400         ; Retry
> >>>                         2419200         ; Expire
> >>>                          604800 )       ; Negative Cache TTL
> >>> ;
> >>> @       IN      NS      localhost.
> >>> @       IN      A       127.0.0.1
> >>> @       IN      AAAA    ::1
> >>>
> >>> *       IN      A       127.0.0.1
> >>>         IN      AAAA    ::1
> >>>
> >>>
> >>> to make localhost and curl.localhost work.
> >>>
> >>> Is this wrong?  and if so, why?
> >>>
> >>> TIA,
> >>> Lee
> >>> --
> >>> 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
> --
> 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
> --
> 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
-- 
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

Reply via email to