Managing localhost

Grant Taylor gtaylor at
Fri Jun 25 01:22:11 UTC 2021

Tony's statements surprised me enough that I shaved them for later deep 
read and pondering.  That time has now come.

On 6/21/21 11:00 AM, Tony Finch wrote:
> That advice is out of date: nowadays you should not put any localhost 
> entries in the DNS, because it can cause problems for web browser 
> security. Modern software should suppress queries for localhost so 
> they never reach the DNS.

If I'm understanding the problem correctly, it seems to come down to 
anything involving localhost /except/ fully qualified 
localhost.(implicit null).

My motivation was wanting to understand how what Tony was relaying 
related to localhost being it's own top level zone with only an A and / 
or AAAA record(s) resolving to and / or ::1 respectively.

I'm still not convinced that fully qualified localhost.(implicit null) 
is a problem in and of itself.  But I see how unqualified localhost can 
~> is a problem.


RFC 6761 section 6.3 seems to support having the fully qualified 
localhost.(implicit null) zone.

Points #4 and #5 makes me think that authoritative responses for fully 
qualified localhost.(implicit null) should be returned.

I feel like BIND's deny-answer-addresses {...} is a very good option to 
help protect against answers that would resolve to, et al. 
Among other things, I have the following:

acl "IANAspecialPurpose" {;          // "This network"                [RFC791], 
Section 3.2          1981-09    N/A         True      False;         // Private-Use                   [RFC1918] 
                1996-02    N/A         True      True;      // Shared Address Space          [RFC6598] 
                2012-04    N/A         True      True;        // Loopback                      [RFC1122], 
Section     1981-09    N/A         False [1] False [1];     // Link Local                    [RFC3927] 
                2005-05    N/A         True      True;      // Private-Use                   [RFC1918] 
                1996-02    N/A         True      True;       // IETF Protocol Assignments     [RFC6890], 
Section 2.1         2010-01    N/A         False     False;       // Documentation TEST-NET-1      [RFC5737] 
                2010-01    N/A         False     False;     // Private-Use                   [RFC1918] 
                1996-02    N/A         True      True;      // Benchmarking                  [RFC2544] 
                1999-03    N/A         True      True;    // Documentation TEST-NET-2      [RFC5737] 
                2010-01    N/A         False     False;     // Documentation TEST-NET-3      [RFC5737] 
                2010-01    N/A         False     False;        // Reserved                      [RFC1112], 
Section 4           1989-08    N/A         False     False; // Limited Broadcast             [RFC8190] 
[RFC919], Section 7  1984-10    N/A         False     True

deny-answer-address {
} except-from {

My understanding, and intention is that anything that returns an address 
that IANA considers to be special purpose ends up filtered.  The only 
exception being my personal domain.  I also have my own networks that 
don't fall within the IANAspecialPurposes ACL listed (...) as their own 
ACLs and should be filtered.

My current takeaway is that localhost.<anything>, other than 
localhost.(null), is verboten, and that localhost.(null) is okay. 
Please enlighten me if this is an incorrect / unsafe takeaway.

Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <>

More information about the bind-users mailing list