---Reply to mail from Marc Haber about read-rfc1918-for-details.iana.net
> Let me follow up on this one. My ISP uses a 192.168 number for a
> router on their network. Formerly, I received a DNS timeout when I did
> a traceroute through that router. Now, I get a
> read-rfc1918-for-details.iana.net reply. I am not in a position to
> change that since my machine uses my ISPs name server.
>
> What are they supposed to do about that? Change their DNS (which won't
> solve the issue for traces coming from the outside) or stop using
> RfC1918 addresses for routers?
>
In all honesty I dont think that counts for the majority of the lookups
done on those (espically after seeing posts here about this)..
I dont see it as a problem even according to the RFC (beucase of the
terming "should not" and "must not").. I also wonder if IANA got some
notices that 'their' routers were broken (based on the almost clever
whoising to whois.arin.net on the IPs returned), but I suspect that this
would be a small ammount if any beucase if people know how to whois, and
to whois arin for IPs they should know about the RFC1918 addrs..
Anyway.. Because there arent enough IPs to go around (becuase some
companies hoarde IPs becuase they got in early and got a class A and use
less than a class B in total, etc :) and beucase some people dont know how
to subnet and issue a class C to people when a smaller network would be
ideal, it seems to me that using RFC1918 addrs for stuff that only needs
tobe directly reachable via internal systems (routers espically, its hard
to DoS a RFC1918 router from outside, and a lot easier to track down if it
occurs from internal) then people should just deal with it..
I personally dont see what the big deal is with the hostname, if you dont
want hte hostname to show up in a traceroute for example you have 2
options.. Filter all RFC1918 traffic from leaving your network.. Or you
can not use any RFC1918 addrs on any machine that may be viewed by
traceroute..
The filtering option would enable you to use RFC1918 addrs, and if you set
them up correctly then you can view from inside and people dont view them
from outside, allowing you to diagnose network problems internally, and
preventing the iana.net domain from showing up..
To put this another way:
What is more fair, IANA takes the network traffic and cpu time resolving
the RFC1918 address or people dont querry IANA for their internal stuff
(which I believe to be 80+% of the total querries for these address)..
Optionally root-servers.net could not have the RFC1918 zones in them, and
this may solve a lot of the problems (since there isnt any routing
information to begin with) that IANA is facing, but then root-servers.net
would still have to process those requests for information on RFC1918
addrs, and they shouldnt have to as well..
There will always be some leakage - espically when you are taling about
dns querries, but if people stop looking up machines on their local
networks, and the only querries are the ones for routers outside your
network when you traceroute for example, then the majority of the problem
IANA faces would go away.. Additionally people will prolly notice faster
responces from systems that have at least empty zones locally (incentive!
:)
But who knows.. Some have said I dont :)
--
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.]
