The power of default configurations
On Mon, 4 Apr 2005, Paul Vixie wrote:
adding more. oh and as long as you're considering whether to restrict things to your LAN/campus/ISP, i'm ready to see rfc1918 filters deployed...
Why does BIND forward lookups for RFC1918 addresses by default? Why isn't the default not to forward RFC1918 addresses (and martian addresses). If a sysadmin is using BIND in a local network which uses RFC1918 address, those sysdmins can change their configuration?
Date: Wed, 6 Apr 2005 18:00:05 -0400 (EDT) From: Sean Donelan <sean@donelan.com> To: nanog@merit.edu Subject: The power of default configurations
On Mon, 4 Apr 2005, Paul Vixie wrote:
adding more. oh and as long as you're considering whether to restrict things to your LAN/campus/ISP, i'm ready to see rfc1918 filters deployed...
Why does BIND forward lookups for RFC1918 addresses by default? Why isn't the default not to forward RFC1918 addresses (and martian addresses). If a sysadmin is using BIND in a local network which uses RFC1918 address, those sysdmins can change their configuration?
RFC1918 space is space you can use inside of an organization in the same way you could use non-RFC1918 space. If a program would treat it differently that would only make sense if that program could only be used in such a way that it would *have* to treat it differently. Regards, JP Velders
* Sean Donelan:
On Mon, 4 Apr 2005, Paul Vixie wrote:
adding more. oh and as long as you're considering whether to restrict things to your LAN/campus/ISP, i'm ready to see rfc1918 filters deployed...
Why does BIND forward lookups for RFC1918 addresses by default?
I think Paul complained about DNS queries with source addresses from RFC 1918 space. It's hard to stop this without using connected UDP sockets.
Why isn't the default not to forward RFC1918 addresses (and martian addresses).
Is the fraction of PTR lookups for RFC 1918 space really that high?
If a sysadmin is using BIND in a local network which uses RFC1918 address, those sysdmins can change their configuration?
They already have to, otherwise the queries won't hit their authoritative servers.
On Thu, 7 Apr 2005, Florian Weimer wrote:
Why isn't the default not to forward RFC1918 addresses (and martian addresses).
Is the fraction of PTR lookups for RFC 1918 space really that high?
Ask the ASN 112 folks how many queries their servers handle. http://www.as112.net/
Ask the ASN 112 folks how many queries their servers handle.
I have a few stats for ISC's AS112 node: - It gets about 2300 DNS UDP queries/sec + about 1300/sec SOA (due to dynamic DNS updates) + about 1000/sec PTR - It also gets about 1200 DNS TCP connections/sec, which appear to be mostly TKEY queries. - Today the busiest source IP address is sending 50 PTR queries/sec. Number two is 30/sec. Duane W.
Ask the ASN 112 folks how many queries their servers handle.
I have a few stats for ISC's AS112 node:
- It gets about 2300 DNS UDP queries/sec + about 1300/sec SOA (due to dynamic DNS updates) + about 1000/sec PTR
- It also gets about 1200 DNS TCP connections/sec, which appear to be mostly TKEY queries.
- Today the busiest source IP address is sending 50 PTR queries/sec. Number two is 30/sec.
...all of which those among you who are OARC members already know :-). -- Paul Vixie
On 4/6/2005 5:00 PM, Sean Donelan wrote:
Why does BIND forward lookups for RFC1918 addresses by default?
As has been pointed out already, caches need to be able to ask other (local) servers for the PTRs. OTOH, it might make a good feature (and eventually maybe a BCP) to block PTR queries for 1918 space from going to the roots and TLD servers. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Wed, 6 Apr 2005, Eric A. Hall wrote:
On 4/6/2005 5:00 PM, Sean Donelan wrote:
Why does BIND forward lookups for RFC1918 addresses by default?
As has been pointed out already, caches need to be able to ask other (local) servers for the PTRs.
OTOH, it might make a good feature (and eventually maybe a BCP) to block PTR queries for 1918 space from going to the roots and TLD servers.
I added something like this to our binds that handle recursive queries. Is there any reason distros (or ISC) couldn't make this a part of the "default config"? zone "168.192.in-addr.arpa" { type master; file "sink"; }; zone "10.in-addr.arpa" { type master; file "sink"; }; ... other similar zones clipped sink is just @ IN SOA localhost. root.localhost. ( 2002100800 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS localhost. * PTR invalid ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 4/7/2005 12:05 PM, Jon Lewis wrote:
I added something like this to our binds that handle recursive queries. Is there any reason distros (or ISC) couldn't make this a part of the "default config"?
This setup works if you know the server is the last resort for your local clients. It doesn't work as a default install unless you are also willing to scream warnings about changing the defaults everytime named.conf is modified for local use. Besides which, you'd really prefer to have an internal filter kill the queries before they are sent to the root (as part of chasing down the delegation chain), or before it was sent to the authoritative servers for in-addr.arpa. (if such was already learned), rather than make users remember to change the configuration file. btw your setup would be technically better if it didn't have the wildcard entry since a negative answer is more accurate. negative caching doesn't work as well as long-lived positive caching, but still, negative answers would be more appropriate.
zone "168.192.in-addr.arpa" { type master; file "sink"; };
zone "10.in-addr.arpa" { type master; file "sink"; }; ... other similar zones clipped
sink is just
@ IN SOA localhost. root.localhost. ( 2002100800 ; Serial 28800 ; Refresh 14400 ; Retry 3600000 ; Expire 86400 ) ; Minimum IN NS localhost.
* PTR invalid
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, 7 Apr 2005, Eric A. Hall wrote:
This setup works if you know the server is the last resort for your local clients. It doesn't work as a default install unless you are also willing to scream warnings about changing the defaults everytime named.conf is modified for local use.
Would you really have to scream? i.e. named (at least on redhat) comes with something like: zone "localhost" IN { type master; file "localhost.zone"; allow-update { none; }; }; $TTL 86400 $ORIGIN localhost. @ 1D IN SOA @ root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum 1D IN NS @ 1D IN A 127.0.0.1 How many admins mess with that? Unless they had reason to (i.e. maybe they use some 1918 space internally and want to setup DNS for it), I doubt that they'd remove similar zone entries intended to be a sink for RFC1918 PTR queries.
Besides which, you'd really prefer to have an internal filter kill the queries before they are sent to the root (as part of chasing down the delegation chain), or before it was sent to the authoritative servers for in-addr.arpa. (if such was already learned), rather than make users remember to change the configuration file.
Defining the zones locally keeps their queries from getting to the root/in-addr.arpa servers. I think I agree with you on losing the * entry, and just letting it return nxdomain. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 4/7/2005 1:02 PM, Jon Lewis wrote:
On Thu, 7 Apr 2005, Eric A. Hall wrote:
Would you really have to scream?
If folks were used to just adding forwarder entries to named.boot, yes, since they'd also have to remember to undelegate authority for the relevant rfc1918 address space now too. If somebody setup a network using a subset of the address space from rfc1918 space they'd have to reconfigure appropriately too. All anybody really cares about is that these queries aren't beating up the root/gtld servers, so adding a check to the referral-chasing would solve that problem and wouldn't impose additional work on the users. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, 7 Apr 2005, Eric A. Hall wrote:
On 4/7/2005 1:02 PM, Jon Lewis wrote:
On Thu, 7 Apr 2005, Eric A. Hall wrote:
Would you really have to scream?
If folks were used to just adding forwarder entries to named.boot, yes, since they'd also have to remember to undelegate authority for the relevant rfc1918 address space now too. If somebody setup a network using a subset of the address space from rfc1918 space they'd have to reconfigure appropriately too.
If they're just caching forwarded queries, as long as the servers they forward to have such sink zones setup, it's not a problem...not for the roots/in-addr.arpa servers anyway. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On 4/7/2005 1:21 PM, Jon Lewis wrote:
On Thu, 7 Apr 2005, Eric A. Hall wrote:
On 4/7/2005 1:02 PM, Jon Lewis wrote:
On Thu, 7 Apr 2005, Eric A. Hall wrote:
Would you really have to scream?
If folks were used to just adding forwarder entries to named.boot, yes, since they'd also have to remember to undelegate authority for the relevant rfc1918 address space now too. If somebody setup a network using a subset of the address space from rfc1918 space they'd have to reconfigure appropriately too.
If they're just caching forwarded queries, as long as the servers they forward to have such sink zones setup, it's not a problem...not for the roots/in-addr.arpa servers anyway.
No, the cache would be authoritative for the zones, so it would null-sink the queries instead of forwarding them to the resolving server -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
On Thu, 7 Apr 2005, Eric A. Hall wrote: If folks were used to just adding forwarder entries to named.boot, yes, since they'd also have to remember to undelegate authority for the relevant rfc1918 address space now too. If somebody setup a network using a subset of the address space from rfc1918 space they'd have to reconfigure appropriately too. All anybody really cares about is that these queries aren't beating up the root/gtld servers, so adding a check to the referral-chasing would solve that problem and wouldn't impose additional work on the users. I don't really want to speak for anyone else here, but it always appeared to me that the problem Vix keeps mentioning is queries with 1918 SOURCE ADDRESSES, not 1918-space queries. This thread, like every nanog thread, has completely lost focus of the original issue, and devolved into some brain-damaged solution to an imagined problem. And if he doesn't find the idea of randomly balkanizing the in-addr.arpa delegation chain for random bits of space abhorrent, I sure do. matto --matt@snark.net------------------------------------------<darwin>< The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
On 4/8/2005 6:19 PM, just me wrote:
I don't really want to speak for anyone else here, but it always appeared to me that the problem Vix keeps mentioning is queries with 1918 SOURCE ADDRESSES, not 1918-space queries.
This thread, like every nanog thread, has completely lost focus of the original issue, and devolved into some brain-damaged solution to an imagined problem.
I don't think it's a bad question. We just went through a similar talk in the zetroconf wg about local addresses. Besides, the question wasn't Paul's in the first place. | From: Sean Donelan <sean@donelan.com> | To: nanog@merit.edu | Subject: The power of default configurations | Message-ID: <Pine.GSO.4.58.0504061756550.5174@clifden.donelan.com> | | On Mon, 4 Apr 2005, Paul Vixie wrote: | > adding more. oh and as long as you're considering whether to | > restrict things to your LAN/campus/ISP, i'm ready to see rfc1918 | > filters deployed... | | Why does BIND forward lookups for RFC1918 addresses by default? Sorry we are bothering you are mail spool. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
In article <42548ACF.9070600@ehsco.com> you write:
On 4/6/2005 5:00 PM, Sean Donelan wrote:
Why does BIND forward lookups for RFC1918 addresses by default?
As has been pointed out already, caches need to be able to ask other (local) servers for the PTRs.
OTOH, it might make a good feature (and eventually maybe a BCP) to block PTR queries for 1918 space from going to the roots and TLD servers.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
The first step in getting these sorts queries stomped on in the right places is coming with the rewording of the ULA draft DNS Issues section which allows nameservers to default to returning rcode 3 (NXDOMAIN/Name Error). The next step is to do this as a general draft which covers all the different suffixes. Mark 4.4 DNS Issues At the present time AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS. For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same locally assigned IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding locally assigned IPv6 Local address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise. Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to locally assigned Local IPv6 addresses; any current form of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse. The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the locally assigned IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer.
participants (9)
-
Duane Wessels -
Eric A. Hall -
Florian Weimer -
Jon Lewis -
JP Velders -
just me -
Mark Andrews -
Paul Vixie -
Sean Donelan