This was coming from the authoritative servers for the RFC 1918 space
zones. It has been planned for more than a year. The data that drove
the change was the exponental increase in the number of queries that
these servers receive. This was an indication that firewall and NAT
designers were becoming "sloppy" and not following the RFC statement
that these addresses should not appear in the Internet. It appears
that besides the "sub-optimal" firewall & NAT implementations, there
are also other commercial packages that object to authoritative
replies. :) This effect was compounded by the terse lable that formed
the query response.
And so the servers are (for now) back in the mode of silently discarding
queries. I have been told that the lable will be reworked to be
more informative and that I will receive instructions to re-enable
authoritative answers soon. (likely a few months out but I don't really
know when).
>
> James & Group(s):
>
> I am cross-posting to bind-users and bind-workers...
>
>
> > From: James Smith <[EMAIL PROTECTED]>
> >
> > Has anyone picked up on the fact that private (rfc1918) IP addresses
> > suddenly started resolving to read-rfc1918-for-details.iana.net in the last
> > few days?
> >
> > This is affecting my, and other's syslog listings and all my machines on our
> > 192.168.x.x internal network behind our NAT box and Firewall.
> >
> > Is this a new decision in the world of TCP/IP that I missed? Also DNS seems
> > to resolve these addresses as this host name (nslookup) this seems to be the
> > seat of the problem, but no one can tell me if this is new.
> >
> > Though this is probably not a Firewall issue it affects private networks
> > which are generally behind Firewalls.... Oh I'm not going to try to motivate
> > why I posted it here, I just wanted the best brains I knew of to brainstorm
> > about the problem.
> >
>
> 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!!!
>
> -------------------------------------------------------------------------------
> 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!!!
> -------------------------------------------------------------------------------
>
>
--
--bill
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
