North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: The power of default configurations

  • From: Paul Vixie
  • Date: Thu Apr 07 12:36:05 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 [email protected] (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