Slashdot Mirror
W2K and MAC OS9 Flood Root Nameservers?
wizzy writes "Irelands toplevel domain registry has a notice on Microsoft and Apple DHCP clients sending dynamic DNS updates per RFC2136. The problem is they are not sufficiently careful about where they send it if they are in RFC1918 space - usually used for behind-firewall addressing, which is where they usually are.. This is resulting in bogus updates being sent at the rate of nearly one million an hour to root nameservers, only to be rejected - as reported on the NANOG mailing list."
They only solve a SYMPTOM of the issue. These people need to set their systems up correctly! Either a) install MS-DNS and point your boxen at that, or b) use BIND, but ENABLE dyn-dns and stop this traffic at the local level. ;)
And if you use a RFC1918 address space, your DNS server should have reverse lookups enabled for that address space - even a split zone so the world won't see them - and that will a) help management of the network easier, and b) prevent problems like this from happening
Another problem is that people are naming their boxes after popular domains
that they don't own, and the dynamic updates are pounding the hell out of the
domain owners nameservers. If anyone here is doing this, owl.com and jove.com
were two of the domains named.
Sealbeater
-- Its survival of the fittest...and we got the fucking guns!!!
No idea about the Mac, but instructions for Windows can be found at http://www.isc.org/ml-archives/bind-users/2000/11/ msg00109.html
:o)
It's pretty funny that the "Win2K is as good as Unix because you don't need to reboot it to change settings" mantra that I hear from MCSE's doesn't apply to this
Specifically, if your WinXP advanced DNS settings look like this, then just uncheck that box.
Hasn't MS had this around for a while now?
They even called it MS-DOS...oh wait, that was Disk Operating System...nevermind.
On the Mac, disable the "DNSPlugin" Network Services Location plugin,
:-)
in the Extensions folder. This applies only to Mac OS 9.0 through
9.2.2; the 8.5-8.6 version of NSL didn't have DNS update support (it
answered SLPv1 broadcasts only, and might have registered with a SLP
DA, I don't remember); the OS X version of NSL doesn't have it
either.
Also note that this registration does not happen always on the Mac,
only if you enable network servers that use NSL (primarily the
personal AFP/file sharing and Web sharing services). I've never
enabled them, so I've never seen this.
Another thing to do is just set your domain so it's one whose
nameservers you control
(Begin liestochildren style technical summary)
In a proper DNS system, you dont have outbound DNS querries except from the DNS server in your network. Hence, blocking all outbound DNS querries works. Each client in the network should be set to querry the networks DNS server, and this in turn querries other servers. (DNS is a recursivly distributed network, your DNS server will pass on your querries on the clients behalf)
Clients should not have to directly querry DNS servers off site or outside of your ISP. Clients should never directly querry the root servers.
What is happening here is that various ISPs and Companies which have large amounts of desktop PCs getting their information via dhcp. These do some house keeping on boot up. If the settings are screwed up either on the desktop or the server, then the dhcp will send off querries and updates to DNS servers it thinks it needs to.
So, if you'r so eleet that you set your internal home network to be slashdot.net, with little nodes such as www for your webcache, you might be causing the real slashdot.net problems. This will be because the dhcp gets confused and thinks it needs to report to its higher up level, the real slashdot.net DNS servers.
If you just have bare nodes like 'foo' and 'bar', then dhcp can be screwed up so it trys to report to the higher up level, the root servers.
As you can track down every system and user who has these things malset, you have to filter on firewalls.
To quote from RFC1918:
It is strongly recommended that routers which connect enterprises to external networks are set up with appropriate packet and routing filters at both ends of the link in order to prevent packet and routing information leakage. An enterprise should also filter any private networks from inbound routing information in order to protect itself from ambiguous routing situations which can occur if routes to the private address space point outside the enterprise.
If you are connecting your internal LAN using a private address space (10/8, 172.16/12, or 192.168/16) you are obviously using a firewall or router configured with NAT.
These need to be configured correctly for many different reasons, including the prevention of the effect mentioned in this article... Add null routes, or packet filter rules for any outgoing packets containing a destination falling in the RFC1918 address space. Also do the same for the incoming packets. By not doing this, you are flooding your upstream provider (in this case the root DNSs) with tons of bogus *(^@.
A few years ago I was lead engineer for a wireless internet company. Our clients were provided with a raw connection, just as if they had gotten a T1. After doing a week long network audit shortly after starting there, I was amazed to find that over 80% of our customer base had internal configuration problems with their NAT setups. Sniffing on the network, I got to see everything from MS Browse messages, DHCP requests, Netware "burbs", and tons of other stuff that should have never left their LANs.
I finally ended up installing firewalls at each POP site, just to dump out the extra junk... Our network speed increased by over 20% just blocking this nonsense at the POP (tower site) and keeping it from coming over our wireless backbone connections... On a typical 16MB/s link that's over 3MB/s of bandwidth we saved.
It appears Ockham lost his razor and grew a beard.
Using a private "unroutable" IP address affords surprisingly little protection. Using techniques like source routing or a compromise of a trusted host, your network can be quickly and easily penetrated.
Firewalls are needed even if you are using private addresses and NAT to access the Internet. In fact, the main reason to use NAT for a local LAN is so that your LAN IP addresses don't conflict with public addresses!
You have to use NAT with these private addresses, or else external connectivity doesn't work. (without a public address, it's damn near impossible to determine how to get the packets back to you!) And that means some things (for example, many network games) either don't work or work in only limited fashion.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
This problem, among with many, many others, was described in a CAIDA paper, "DNS Measurements at a Root Server." They basically ran TCPDump on root server F, and analyzed the traffic. An amazing number of invalid requests are sent all the time. It really shows how important it is for network admins to correctly set up their name services, but it also identifies problems caused by bugs in software. Very interesting read: http://www.caida.org/outreach/papers/2001/DNSMeasR oot/
http://www.domainregistry.ie/tech/dynamic-dns.html tells you how to disable the 'registration' problem with MacOS and NT.
The bigger problem is that of making sure you use sane name spaces, and never conflict with real ones.