At 11:16 AM 2/20/2007, Andrew Sullivan wrote:
On Tue, Feb 20, 2007 at 10:30:23AM +0000, Jim Reid wrote:
> No Ed, they're ambiguous. Paul's right. Consider two companies each
> of whom use 10/8 on their intranets.
Surely, to the extent they're ambiguous, they're ambiguous by design.
RFC 1918 addresses are supposed to have local scope. If you have
changed the meaning of "local" without resolving the conflicts in the
scope of two former meanings of "local", that's an operator error.
If what people are saying is, "RFC 1918 addresses are bad because they
leak past the local boundaries sometimes," fine. I have to agree with
Ed, though, that hacking up the DNS to solve a problem that is not
strictly a DNS issue is a mistake. It might be, however, that
guidelines for routing or for how to connect RFC 1918-addressed hosts
to other hosts are needed. Those don't seem to be DNS issues, though.
DNS server software generally ships with a config file. In the case
of BIND, it ships with a config that provides a caching server, at
least on most distributions of Linux and whatnot.
As I've watched this whole discussion develop, I've been thinking
"why are people so polarized over having the DNS server software
packages ship with a default config file that limits leakage of RFC
1918 addresses?"
I see no problem with a starting config that provides such limits as
ignoring packets to/from RFC 1918 addresses and passing of RRs that
contain RFC 1918 addresses. This won't preclude anyone with 1/2 a
clue from configuring the software to more fully reflect their needs.
This is an issue of doing something in the default case that will
benefit the worldwide network.
A similar example is the sendmail package distributed with some
flavors of Linux (perhaps with other systems too) which only listens
to 127.0.0.1 by default, does not relay mail for other machines, etc.
The POINT we should be agreeing on is that the example config file,
the default config file or whatever, should be well crafted to avoid
unnecessary noise on the Internet. I see no reason for the underlying
code in BIND or any other DNS server to be altered to behave differently.
The network's grown over the years, and isn't the friendly place it
once was. Not everyone implementing servers understands the
implications of default configurations that might allow propagation
of attacks. From time to time we need to re-evaluate this. Some years
ago we altered RFC 1812 (Router Requirements) with a subsequent
document to change a default (directed broadcast) because we found it
was an attack vector, and most of the time people didn't need the
feature. Users who need it can turn it back on. The choice of
defaults, ESPECIALLY those which are simply a sample, default or
recommended starting point config should not result in the world
ending, and may just be beneficial.
Please take a few minutes BEFORE you reply to this or other emails on
this thread, think about what is really being discussed, then flame away.
Dan
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
