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
> 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:
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.
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.
In article <42548ACF.9070600@ehsco.com> you write:
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.
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.
>
> http://www.as112.net/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 :-).
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
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.
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.
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.
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
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
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>> 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.