[79444] in North American Network Operators' Group
Re: The power of default configurations
daemon@ATHENA.MIT.EDU (Christopher L. Morrow)
Thu Apr 7 14:07:17 2005
Date: Thu, 07 Apr 2005 18:04:44 +0000 (GMT)
From: "Christopher L. Morrow" <christopher.morrow@mci.com>
In-reply-to: <20050407174135.107D013E3F@sa.vix.com>
To: nanog@merit.edu
Errors-To: owner-nanog@merit.edu
On Thu, 7 Apr 2005, Paul Vixie wrote:
>
> > no to 1) prolong the pain, 2) beat a horsey.. BUT, why are 1918 ips
> > 'special' to any application? why are non-1918 ips 'special' in a
> > different way?
>
> i know this is hard to believe, but i was asked to review 1918 before it
> went to press, since i'd been vociferous in my comments about 1597. in
> the text (RFC 1918) we see the following:
<snip>
>
> yikes! i think i contributed some of that text. and i see now that it
> really does have to say something about dns forwarders. so i'll withdraw
> my suggestion that this thread be moved to bind-users@ -- it needs to go
> to dnsop@lists.uoregon.edu since it's not a BIND-specific issue at all.
>
So, this highlights some good operational practices in networking and
DNS-applications, but doesn't answer how 1918 is 'different' or 'special'
than any other ip address. I think what I was driving at is that putting
these proposed road blocks in bind is akin to the 'cisco auto secure'
features.
Someone is attempting to 'secure' the problem (both the network and the
application problems) here in the same manner. The practices outlined in
the RFC paul quoted, if followed, should do this... So, the problem isn't
that technology is required to fix this, its that people aren't doing
the required things to make the pain stop (at the enterprise or individual
site level).
Making the distinction between 1918 and 'other' seems, atleast at the
equipment or application level, like a recipe for disaster. As paul
mentioed wrt Microsoft earlier: There are many an enterprise out there
with 1918 in siteX/Y/Z and 'globally unique ip space' in sites A/B/C.
