On Feb 19, 2007, at 11:56, Edward Lewis wrote:
At 11:34 +0000 2/19/07, Jim Reid wrote:
Right. But it depends on what's meant by "extra measures". IMO
it's more than
reasonable to have a default that says "don't do reverse lookups
of 1918
addresses on the Internet". This would be a Very Good Thing. If
this was in
place, the extra measures would then be for someone using 1918
addressing to
switch off that default and properly configure their server for
the local
network.
I disagree about the "Very Good Thing."
If I am using RFC 1918 space locally I will use those addresses in
my local forward DNS and have a local reverse DNS. My remote-
facing DNS will not have those addresses and hence not have any
reverse zones.
Part of the problem is that the DNS server doesn't know if it is
doing "reverse lookups of 1918 addresses on the Internet" or if it
is doing reverse lookups of 1918 addresses on the company Intranet.
Which in the final analysis is a matter of configuration. Which is
where this needs to be done anyway because it depends on local
policy. For the scenario you describe, this needs to be done no
matter what default exists or doesn't exist.
You simply have to tell your server whether it's resolving local or
"public" 1918 space. Or not resolving it at all.
IMO, it's better if there's a sensible default configuration -- for
some definition of sensible -- that works "right out the box". This
has to be an improvement on leaving things undefined, usually
misconfigured and DNS administrators in complete ignorance of the
problems that this misconfiguration causes for others.
In a way this parallels the early days of inetd. Once upon a time
this was shipped with a default config file that had everything
enabled. Admins mostly left inetd.conf alone because they assumed it
was set up the way the OS vendor wanted. Nowadays, everything is
usually switched off by default, forcing the admin to make a
conscious decision to enable service: ie implicitly define and
implement local policy. Why can't we learn from that experience?
Sorry folks if I'm being dense or just ornery about fooling with
Mother Nature here. If you start bending the DNS protocol to route
around damage in other parts of the network architecture, you'll be
weakening one more element.
I fail to see how changing -- I'd say defining -- the default
behaviour of a name server in this way could possibly be a protocol
issue.
Another desirable default resolver configuration would be to refuse
recursive queries from non-local addresses.
How? What's local? What's not local? Do you want to see the name
server be required to also speak the local routing protocols to
determine what's inside and what's outside?
Ed, you're being ridiculous. All I was suggesting here was, in BIND
terms, making "allow-recursion { localnets; };" the default. This has
to be preferable to the current situation of a free-for-all for
everyone. If that default isn't right, then the admin is required to
make a conscious act to make the server comply with local policy.
Which they should be doing anyway of course. Where's the harm?
Remember that the more you stuff into the configuration files, the
more you are going to cost the operators that have to manage the
configurations.
True enough. But there are trade-offs here. Tweaking a handful of
config file options is a one-off cost. And has the side-effect of
minimally documenting local policy, if only through reading the
config file. The consequences of bad defaults and undefined
configurations leaves many name servers creating all sorts of
trouble. Worse, the trouble is for others and the local DNS admin is
blissfully unaware of that. ISTR 40-60% of root server traffic would
go away if people using 1918 addressing configured their name servers
properly. IMO this WG shouldn't wash its hands of this problem,
claiming its a protocol issue and not an operational one. Which is
what you appear to suggesting Ed. I hope not.
First let's talk about whether it is a problem to have RFC 1918
space exposed as an address for a nameserver.
It is.
Second, let's talk about the severity, and is there some real
threat to others if someone does this.
There is.
Third, then let's talk about placing safeguards up.
I refer you to my previous posting. :-)
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
