The power of default configurations

Thu Apr 7 16:34:50 UTC 2005

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