Managing localhost

Grant Taylor gtaylor at tnetconsulting.net
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 127.0.0.1 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.

> https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html
> 
> https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

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 127.0.0.1, et al. 
Among other things, I have the following:

acl "IANAspecialPurpose" {
    0.0.0.0/8;          // "This network"                [RFC791], 
Section 3.2          1981-09    N/A         True      False
    10.0.0.0/8;         // Private-Use                   [RFC1918] 
                1996-02    N/A         True      True
    100.64.0.0/10;      // Shared Address Space          [RFC6598] 
                2012-04    N/A         True      True
    127.0.0.0/8;        // Loopback                      [RFC1122], 
Section 3.2.1.3     1981-09    N/A         False [1] False [1]
    169.254.0.0/16;     // Link Local                    [RFC3927] 
                2005-05    N/A         True      True
    172.16.0.0/12;      // Private-Use                   [RFC1918] 
                1996-02    N/A         True      True
    192.0.0.0/24;       // IETF Protocol Assignments     [RFC6890], 
Section 2.1         2010-01    N/A         False     False
    192.0.2.0/24;       // Documentation TEST-NET-1      [RFC5737] 
                2010-01    N/A         False     False
    192.168.0.0/16;     // Private-Use                   [RFC1918] 
                1996-02    N/A         True      True
    198.18.0.0/15;      // Benchmarking                  [RFC2544] 
                1999-03    N/A         True      True
    198.51.100.0/24;    // Documentation TEST-NET-2      [RFC5737] 
                2010-01    N/A         False     False
    203.0.113.0/24;     // Documentation TEST-NET-3      [RFC5737] 
                2010-01    N/A         False     False
    240.0.0.0/4;        // Reserved                      [RFC1112], 
Section 4           1989-08    N/A         False     False
    255.255.255.255/32; // Limited Broadcast             [RFC8190] 
[RFC919], Section 7  1984-10    N/A         False     True
};

deny-answer-address {
    ...
    IANAspecialPurpose;
    ...
} 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: <https://lists.isc.org/pipermail/bind-users/attachments/20210624/87c22a67/attachment.bin>


More information about the bind-users mailing list