There was actually a very interesting discussion about this very topic regarding the proposed new ULA addresses at ipv6 working group at the last IETF meeting. This included a discussion about who should do the filtering the routers or the DNS servers etc...see the minutes below.
http://www1.ietf.org/mail-archive/web/ipv6/current/msg04554.html
The IESG basically rejected this draft because of the issues of DNS queries for 1918 space. They were looking for stronger language to deal with the issue we currently see with 1918 queries.
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-unique-local-addr-09.txt
Andrew
> > 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.
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?
-Chris
Because they're 'special.'
But you are correct, there is nothing special about RFC1918 at the
network.
If people did proper source address validation they wouldn't send RFC1918
addresses along with a lot of other junk. RFC1918 are actually a very
small amount of the junk packets, they are just easy for people like
Paul to detect. Its just harder to detect the other mis-configured
address ranges. CYMRU bogons are pretty funny when you think about
it, if the bad guys can spoof packets why would they spoof address
ranges that are easy to filter? You want anti-spoofing of all addresses,
not special address ranges.
The other side. A lot of software programmers and network architects and
security consultants think RFC1918 addresses are special. This leads
to a lot of mis-configured (or more precisely, never configured) software.
How can we make more software "safe by default?" Because relying on the
user or sysadmin to make it safe isn't working. That includes safe
default configurations that are conservative in what they send, such as
doing RFC1918 lookups against root name servers. The original BIND
from Berkeley included a "localhost" file, why not a "workgroup" file
and an RFC1918 file?
And, to tie the thread title back in to one example of what you're
saying there, five years ago when I first saw NANOG, there might have
been a reason why you had to let forged source addresses leak through
your edge devices...
but that was five years ago. Have manufacturers *really* not made that
item a default by now? Have providers *really* not changed out that
equipment in five years? I mean, this is internet time, right?
Cheers,
-- jra
but that was five years ago. Have manufacturers *really* not made that
item a default by now? Have providers *really* not changed out that
yes, they really haven't 
more people ought to reference RFC3871 in
their RFP's and stop accepting sub-standard equipment? ..dreams...
equipment in five years? I mean, this is internet time, right?
Yes, reference bubble-bursting, reference '100% growth of bandwidth each
year' misrepresentations... backbone/network/company consolidations...
oh well.