Hi Robert. Having localhost in /etc/hosts works if both of these conditions are satisfied, I think: 1) The client asking the question is on the same box. 2) /etc/nsswitch.conf has been configured to look in hosts first, DNS second
If the client is local but nsswitch says to do DNS first then nameserver entries in /etc/resolv.conf determine where queries are sent, which could be a local instance of BIND. If the local BIND is authoritative for localhost/.local etc. then it should respond in microseconds. I don't know how this would compare with a lookup into hosts. I suspect hosts would be slower since it requires disc access? Unless hosts is cached?. Honestly, I don't know the answer to that one. If the client is remote it won't go anywhere near hosts, so it might be useful to have localhost in DNS anyway? My 2p. Cheers, Greg On Tue, 14 Jan 2025 at 11:56, Robert Wagner <rwag...@tesla.net> 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. > 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. > ------------------------------ > *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
