The power of default configurations

Paul Vixie paul at vix.com
Thu Apr 7 17:41:35 UTC 2005


> 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:

   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links. Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks. If such a router receives
   such information the rejection shall not be treated as a routing
   protocol error.

well, so much for the importance of "shall not" in rfcspeak, huh?

   It is strongly recommended that routers which connect enterprises to
   external networks are set up with appropriate packet and routing
   filters at both ends of the link in order to prevent packet and
   routing information leakage. An enterprise should also filter any
   private networks from inbound routing information in order to protect
   itself from ambiguous routing situations which can occur if routes to
   the private address space point outside the enterprise.

"blah, blah, blah, ginger, blah, blah." --what your dog hears (gary larson)

   If an enterprise uses the private address space, or a mix of private
   and public address spaces, then DNS clients outside of the enterprise
   should not see addresses in the private address space used by the
   enterprise, since these addresses would be ambiguous.  One way to
   ensure this is to run two authority servers for each DNS zone
   containing both publically and privately addressed hosts.  One server
   would be visible from the public address space and would contain only
   the subset of the enterprise's addresses which were reachable using
   public addresses.  The other server would be reachable only from the
   private network and would contain the full set of data, including the
   private addresses and whatever public addresses are reachable the
   private network.  In order to ensure consistency, both servers should
   be configured from the same data of which the publically visible zone
   only contains a filtered version. There is certain degree of
   additional complexity associated with providing these capabilities.

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 at lists.uoregon.edu since it's not a BIND-specific issue at all.



More information about the NANOG mailing list