nanog mailing list archives

Re: The power of default configurations


From: Paul Vixie <vixie () vix com>
Date: 07 Apr 2005 16:34:50 +0000


 > adding more.  oh and as long as you're considering whether to
 > restrict things to your LAN/campus/ISP, i'm ready to see rfc1918
 > filters deployed...
 
 Why does BIND forward lookups for RFC1918 addresses by default?  Why
 isn't the default not to forward RFC1918 addresses (and martian
 addresses).  If a sysadmin is using BIND in a local network which uses
 RFC1918 address, those sysdmins can change their configuration?

i asked this question of microsoft, in a slightly different form.  (since
the vast installed based of RFC2136 clients is windows/2k and windows/xp.)
i wanted to know, why does a client whose address is in RFC1918 address
space _ever_ send an update to a server that is not in RFC1918 address
space?  their answer was, many of their large enterprise customers run in
exactly that configuration, and the defaults have to Just Work in that case.

it's quite a conundrum.  the router people wish that the application people
would take care of RFC1918 bordering, and the application people with that
the router people would take care of RFC1918 bordering.

but this is the first time i can remember anyone blaming BIND.  interesting
approach.  please move this discussion to bind-users () isc org (or even better,
to one of the closed bind-forum mailing lists), and i promise that if some
kind of proposal comes to light out of all the resulting heat, it'll come
back to nanog for ratification.

if there's something BIND can do to help with the RFC1918 bordering problem,
without causing more harm than good, then you can bet it'll get done.
-- 
Paul Vixie


Current thread: