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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please 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
