Re: Address match lists syntax, was Managing localhost
No, there is no need to redefine localhost acl. It is built-in and already specifies localhost IPv4 and IPv6 address. similar to localnets (networks directly connected to the server), any or none names. Read a great ARM documentation about BIND [1], it has section about ACLs describing build-in names. Just use localhost, whatever should not be served to outside network. The best way to protect your service is to listen only to localhost address however. Cheers, Petr 1. https://bind9.readthedocs.io/ On 6/25/21 1:04 PM, Alessandro Vesely wrote: > Ooops, sorry. Please forget that. > > On Fri 25/Jun/2021 12:50:55 +0200 Alessandro Vesely wrote: >> However, named-checkconf doesn't complain. I could fix that by >> defining an acl named localhost. But do I need to? > > > Now I tried to redefine and got: > > /etc/bind/named.conf.options:37: attempt to redefine builtin acl > 'localhost' > > > >> >> Best >> Ale -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB ___ 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
Re: Managing localhost
Grant Taylor via bind-users wrote: > 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). Correct. As I mentioned in the blog post (link repeated below), I did some data collection to verify that dropping the localhost subdomains would be safe: answer, yes, there were basically no localhost queries. I used to have a bunch of zones related to special-use domain names and IP addresses, but after BIND 9.12 added support for DNSSEC-based NXDOMAIN synthesis, I deleted them all. This means that (strictly speaking) my servers don't conform to RFC 6761's requirements for localhost, but (a) I can say that it is BIND's bug rather than mine, and (b) it doesn't matter anyway because the query traffic is negligible. > > https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html > > https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 Tony. -- f.anthony.n.finchhttps://dotat.at/ Faeroes: Variable 2 to 4, becoming southwest 5 to 7. Slight or moderate, becoming moderate or rough. Occasional rain later. Good, occasionally moderate later. ___ 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
Re: Address match lists syntax, was Managing localhost
Ooops, sorry. Please forget that. On Fri 25/Jun/2021 12:50:55 +0200 Alessandro Vesely wrote: However, named-checkconf doesn't complain. I could fix that by defining an acl named localhost. But do I need to? Now I tried to redefine and got: /etc/bind/named.conf.options:37: attempt to redefine builtin acl 'localhost' Best Ale -- ___ 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
Address match lists syntax, was Managing localhost
Hi,
I found a number of allow-query {localhost;}; and similar stuff in my .conf
files. It doesn't seem to be allowed, since the manual says:
The elements which constitute an address match list can be any of the
following:
* an IP address (IPv4 or IPv6)
* an IP prefix (in `/' notation)
* a key ID, as defined by the key statement
* the name of an address match list defined with the acl statement
* a nested address match list enclosed in braces
However, named-checkconf doesn't complain. I could fix that by defining an
acl named localhost. But do I need to?
Best
Ale
--
___
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
Re: Managing localhost
Am 25.06.21 um 03:22 schrieb Grant Taylor via bind-users: 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 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. he is talking about "localhost.example.com" and nothing else ___ 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
Re: Managing localhost
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 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-09N/A True False
10.0.0.0/8; // Private-Use [RFC1918]
1996-02N/A True True
100.64.0.0/10; // Shared Address Space [RFC6598]
2012-04N/A True True
127.0.0.0/8;// Loopback [RFC1122],
Section 3.2.1.3 1981-09N/A False [1] False [1]
169.254.0.0/16; // Link Local[RFC3927]
2005-05N/A True True
172.16.0.0/12; // Private-Use [RFC1918]
1996-02N/A True True
192.0.0.0/24; // IETF Protocol Assignments [RFC6890],
Section 2.1 2010-01N/A False False
192.0.2.0/24; // Documentation TEST-NET-1 [RFC5737]
2010-01N/A False False
192.168.0.0/16; // Private-Use [RFC1918]
1996-02N/A True True
198.18.0.0/15; // Benchmarking [RFC2544]
1999-03N/A True True
198.51.100.0/24;// Documentation TEST-NET-2 [RFC5737]
2010-01N/A False False
203.0.113.0/24; // Documentation TEST-NET-3 [RFC5737]
2010-01N/A False False
240.0.0.0/4;// Reserved [RFC1112],
Section 4 1989-08N/A False False
255.255.255.255/32; // Limited Broadcast [RFC8190]
[RFC919], Section 7 1984-10N/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., 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
Re: Managing localhost
Thank you Kevin and Tony!! On 2021-06-21 10:07, Kevin Darcy via bind-users wrote: [ Classification Level: GENERAL BUSINESS ] That chapter doesn't show any PTR records, for the reverse zones of any *public* address range, pointing back to a "localhost" name. It only shows a PTR record in the reverse zone for the 127.0.0/24 private range, which is what enables a reverse lookup for 127.0.0.1. Your ISP isn't (or shouldn't be) hosting reverse zones for any range under the 127/8 private block, on your behalf. That's your responsibility; hence the term "private". And, as Tony mentioned, these days it's highly questionable whether "localhost" entries in *any* zone, forward or reverse, serve any useful purpose, and may actually cause harm. - Kevin On Mon, Jun 21, 2021 at 12:48 PM wrote: Hi, This book : https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html says I should manage the localhost within my zone (SOA) and reverse lookup / PTR. I do not manage my revers lookup / PTR the IP owner does that. Any thoughts on managing the localhost within the zone file and PTR? Thanks!! ___ 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 ___ 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 ___ 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
Re: Managing localhost
[ Classification Level: GENERAL BUSINESS ] That chapter doesn't show any PTR records, for the reverse zones of any *public* address range, pointing back to a "localhost" name. It only shows a PTR record in the reverse zone for the 127.0.0/24 private range, which is what enables a reverse lookup for 127.0.0.1. Your ISP isn't (or shouldn't be) hosting reverse zones for any range under the 127/8 private block, on your behalf. That's your responsibility; hence the term "private". And, as Tony mentioned, these days it's highly questionable whether "localhost" entries in *any* zone, forward or reverse, serve any useful purpose, and may actually cause harm. - Kevin On Mon, Jun 21, 2021 at 12:48 PM wrote: > Hi, > > This book : > https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html > says I should manage the localhost within my zone (SOA) and reverse > lookup / PTR. > > I do not manage my revers lookup / PTR the IP owner does that. > > Any thoughts on managing the localhost within the zone file and PTR? > > Thanks!! > ___ > 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 > ___ 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
Re: Managing localhost
techli...@phpcoderusa.com wrote: > > This book : > https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html says I > should manage the localhost within my zone (SOA) and reverse lookup / PTR. 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. https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html https://datatracker.ietf.org/doc/html/rfc6761#section-6.3 Tony. -- f.anthony.n.finchhttps://dotat.at/ no one shall be enslaved by poverty, ignorance, or conformity ___ 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
Managing localhost
Hi, This book : https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html says I should manage the localhost within my zone (SOA) and reverse lookup / PTR. I do not manage my revers lookup / PTR the IP owner does that. Any thoughts on managing the localhost within the zone file and PTR? Thanks!! ___ 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
