---Reply to mail from Stefan Jon Silverman about read-rfc1918-for-details.iana.net
After seeing how many people didnt have empty (or filled in) zones for
these addrs, it kinda makes me wonder if iana got sick of all the dns
querries to their site for RFC1918 addresses and wanted people to stop
trying to resolve externally for a name that wouldnt ever be what they set
it to, thus 'incorrect'..
I did zones for RFC1918 addrs when we first started using them, so that we
could more easily use hostnames rather than IPs and so that we could see a
little easier who was doing what on the network (and make it faster for
connects espically when there is high congestion and DNS is slow anyway)..
What ever the case, the fix seems really simple.. If you want to turn off
RFC1918 resolution, then add empty zones into your named.[boot|conf] and
poof its 'fixed' I think that adding to the general complexity of the
code, adding in extra features that arent really needed is it so much
harder to create these zones (you can use the same zone file for all the
RFC1918 addrs, if you just want it empty) than it is to write emails, and
write code to check for RFC1918, and ...
If the problem is one where the hostnames are breaking DNS then shame on
you for relying on outside data for your internal network names :)
With this said, did I miss anything?? Is there really a reason to modify
bind that I am not seeing??
For those that dont know where to get RFCs (and to prevent people from
asking) you can find it at: ftp://ftp.isc.org/pub/rfc/rfc1918.txt
There are a lot of other places, but that should work for everyone..
Now as to the question below: Yes RFC1918 addrs come from root servers
saying that IANA owns those addresses.. If you whois the addresses (use
host whois.arin.net for IPs) you will see that there too IANA is listed as
the owner of those IPs.. This appears to be the correct behaviour for
them.
> To the firewallers:
>
> Hmmm...very interesting, this started showing up at one of the
> sites I manage yesterday in the Socks5 logs...
>
> After doing all of the usual things (since we had done a
> net-topo change on the inside of the firewalls) to try and clear it up
> - restart socks, various dns named processes, and finally a reboot with
> no effect - I started digging into the dns setup and discovered that my
> upstream resolvers were passing this to me. Not having the time to
> delve deeper, and thinking that this was just something they were doing
> because too many queries were leaking from us, I just dummied up some
> zones on the 127.0.0.1 instantiation of named (we use 4 -- outside /
> InterNet, rednet / inside-border, dmz / servers, and localhost with a
> cascading forwarder scheme -- uggh, but it is all on the same machines,
> IPC even over sockets is not that bad) and the problem cleared
> up...socks is happily resolving from the dummy zones and life goes on
> (although at the cost of a lot of cpu cycles)
>
> To the binders:
>
> Should there be an option in 8.2.x to specifically turn off
> resolution (on a per-interface basis) for resolution of the rfc1918
> range of addresses???
>
> And is this coming from the root servers???
>
> Regards,
>
> b c++'ing u,
>
> %-) sjs
>
> PS: I am my own employer, therefore: "all opinions are twice spoken for;"
> and they do, in fact, scare the hell out of said employer!!!
>
--
Bret McDanel http://www.rehost.com
Realistic Technologies, Inc. 973-514-1144
These opinions are mine, and may not be the same as my employer
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
