Re: The power of default configurations
-------Original Message-------
From: "Sean Donelan" <sean@donelan.com> Subject: The power of default configurations Sent: 06 Apr 2005 14:00:05
On Mon, 4 Apr 2005, Paul Vixie wrote:
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?
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. -- Paul Vixie
On Thu, 7 Apr 2005, Paul Vixie wrote:
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.
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
On Thu, 7 Apr 2005, Christopher L. Morrow wrote:
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?
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?
On Sun, Apr 10, 2005 at 09:15:39PM -0400, Sean Donelan wrote:
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 -- Jay R. Ashworth jra@baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
On Sun, 10 Apr 2005, Jay R. Ashworth wrote:
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.
participants (5)
-
Andrew Dul -
Christopher L. Morrow -
Jay R. Ashworth -
Paul Vixie -
Sean Donelan