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."
With Photoshop 7 out and this, now Mac OS9 users have an even better reason to upgrade to OS X - "to save the Internet." :)
"The objective of securing the safety of Americans from crime and terror has been achieved." -- John Ashcroft
Yet another reason to use firewalls to filter _OUTGOING_ connections and not only incoming ones (the other reason : to avoid backdoors) .
{{.sig}}
Before everyone jumps down MS's throat (or Apple's) does anyone know how to reconfigure a system to fix this issue?
3000 dead over past 2 years, still no free Palestinians, still
I know these problems. In my small ISP company, we ar running our own nameserver.
The logs are flooded from rejected name server updates (several hundreds a day).
They are mostly coming from misconfigured W2K servers from our customers, running their intranet with DHCP and using the same domain as in the real net.
Sadly, we contacted the administrator, but he didn't have a clue what I was talking about (they're justig running windows on their server because they know windows...)
Usually I would suggest to use an internal domain name that doesn't exist in the internet and just "masquerade" the mail domains. So resolving internal addresses from extern fails if some information slips out and the internal servers won't resolve some external name server to contact when an internal server should be.
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!!!
I wonder if adding NS records for the bogous in-addr.arpa domains would help, i.e.:
168.192.in-addr.arpa NS 192.168.1.1
10.in-addr.arpa NS 10.0.0.1
...
Claus
A Microsoft spokesman said, "Thing is, is that those root nameservers would all be fine if they were running Win2K DNS services. " :)
Get your own free personal location tracker
Specifically, if your WinXP advanced DNS settings look like this, then just uncheck that box.
why is this the first time that anyone's noticed this?
You think that just because you read this article on Slashdot today that it was "just noticed" as of yesterday or something?
Gee, thanks a lot.
So you get what you pay for. You drive down the perceived value of a Microsoft sys admin and you fill these positions with poorly trained or MCSE certified test takers with no real grasp of the larger issues involving administer *any* IT site.
Any competent sys admin would ensure crap like this doesn't happen, no matter what the OS is.
And if the gap in pay and value between Unix and Windows sys admins is widened, who in their right mind coming out of a CS degree in college (not some fly-by-night certification course) is going to want to use their training to specialize in the market that pays the least?
Hasn't MS had this around for a while now?
They even called it MS-DOS...oh wait, that was Disk Operating System...nevermind.
The TCP/IP is very, very different on those two different OSes.
Windows, IIRC, uses sockets. Mac OS 9 uses streams (although Mac OS X uses sockets). It's very unlikely that someone stole someone else's TCP/IP code, as much as I would like to blame Microsoft for stealing code...
It's not the same bug. Windows, by default, is trying to put its name into the MS Active Directory stuff, which is implemented using Dynamic DNS. The Mac OS 9 systems only try to do this if you have either TCP/IP Personal File Sharing or Personal Web Sharing enabled--which both default to off...and even if you turn on File Sharing the TCP/IP connectivity defaults to off.
Actually this does not sound at all like an issue that should've been caught in user testing. There is no magic to software testing, and it's a thoughtless misconception to think that "good" software testers will catch every conceivable issue. Software testing catches what the software testers are looking for. Any other issues have to be fairly obvious to be caught, in most cases.
You know, I never understood why they did this as default. And I am also surprised it took this long for anyone to loudly complain. First thing I have always done when installing 2k/xp machines that don't need it is uncheck that option.
MS clients should not attempt this unless they are on a 2k AD domain. This is also as someone pointed out a good reason to filter your outgoing traffic.
It reminds me of when they had that check for "logon" enabled by default for ppp connections, when 90% of ISP's didn't support this.
If you wanna get rich, you know that payback is a bitch
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/
How often does Win2K register these ip addresses? Is it once an hour or so, or is there really a million win2k boxes being rebooted every hour?
I guess we should be happy that they don't link to Apple and Microsoft as well ;-)
"I love my job, but I hate talking to people like you" (Freddie Mercury)
What is it with people and writing MAC instead of Mac?
Mac is short for Macintosh, it's not a bleeding acronym! I can put up with it when it comes to ignorant posters, but seriously, shouldn't the Slashdot editors know better?
is here.
/not/ funny seeing a ten megabyte logfile produced every seven minutes. I wonder what they use for logfile analyses, I think it's getting more information than it's able to process.
It's funny to see a ten megabyte logfile produced every seven minutes *SLAP* woops. It's
Edwin
bash$