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