Bret and Group(s):
> From: Bret <[EMAIL PROTECTED]>
>
> ---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??
>
Well, not quite broken DNS but the security policy I like to
enforce about having as little inside information leakable by the
firewall as possible if it is in any way compromised.
We do use the 192.168.x.x ranges inside and have several
servers dedicated to resolving for the local community, when they can't
resolve they forward to the firewalls on the assumption that it is
probably and InterNet query anyway.
We use another 192.168.x.x for what we call the rednet zone
between the dual firewalls and the inside screening router (in this
case one instantiation of named listens on the inside interfaces of the
firewalls as SOA and the zones are then slaved to the inside servers
for caching and CNAME'ing to more humanly understandable pseudonyms,
i.e., socks.my_domain.com instead of socks-nyc-01.rednet.my_domain.com).
Another 192.168.x.x sub-net hangs off the back of the firewalls
going to the web and other InterNet application servers (I won't
re-introduce the DMZ argument of a while ago) for use by reverse
proxies slaved to the InterNet interfaces for access to the web
sites and other services. CNAME's and more CNAME's -- I also like
simple names for services that translate to the real name(s) so
that fail-over and load-sharing can be more easily accomplished.
The firewalls themselves are SOA for the InterNet visible
addresses on an outward listening named. I have also instantiated a
localhost zone (127.0.0.1) for the firewalls own housekeeping (i.e.,
proxies that like to resolve names - inside and out - and such). It
too forwards to the InterNet named, not inside.
What I hadn't realized was that the socks proxy was trying
really hard to resolve all of the inside hosts that were using it.
This apparently was the source of our leaking to the InterNet because
the localhost named would ask the InterNet named who would then pass
it upstream and of course it would not resolve. This would also
explain the occassional latency on proxy use, our upstream resolvers
are very busy puppy's...
Now, it may be suggested that I slave our inside 192.168.x.x
zones back to the firewalls from inside to allow proper host names
to show up in the logs (of some value, but if necessary a little
scripting on the inside logs will give me all of the real names),
___BUT___ a major violation of my rule about leakable information
being persistent on the firewalls. The only legitimate inside
machines that I want the firewalls to have any knowledge of
whatsoever would be the mail-relay servers and the administration
machines. For the moment I have dummied the zone entries of all
but the machines the firewall needs to know about but this could
rapidly become a maintenance headache as additional class 'C'
sub-nets are added.
So, and now comes the feature thing you have been waiting
for...I would love a switch or config option that I could turn on
on the external InterNet instantiation of named that would basicly
tell it to bit-bucket rfc1918 addresses and immediately return
an "unresolved" answer. That way my proxies would be happy and
the greater InterNet wouldn't see all of my leaking dns query
traffic...
Hope this clears up the thinking a little and provokes
some more interesting discussion...
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!!!
-------------------------------------------------------------------------------
Stefan Jon Silverman - President SJS Associates, N.A., Inc.
Suite 15-B
Inter-/Intra-Net Architecture, Implementation & Security 698 West End Avenue
New York, NY 10025
E-mail: [EMAIL PROTECTED] Phone: 212 662 9450
Website: http://www.sjsinc.com Fax: 212 662 9461
Text-Page: [EMAIL PROTECTED] Cell: 917 929 1668
-------------------------------------------------------------------------------
Weebles wobble, but they don't fall down!!!
-------------------------------------------------------------------------------
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
