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