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."
Yet another reason to use firewalls to filter _OUTGOING_ connections and not only incoming ones (the other reason : to avoid backdoors) .
{{.sig}}
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
There are a couple thousand Windows machines of various flavors inside my network and they are constantly generating crap lookups. I see my poor machines forwarding them to the outside, no doubt pissing someone off.
Where 'FOO' is one of our servers:
FOO.k12.co.us
FOO.co.us
FOO.us
FOO (this is what hits the root servers)
These things are trying to do DNS even when WINS would have a perfectly good answer. Multiply this by thousands of lemming systems and you have a bunch of load that should never be there.
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
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
I believe this is the actual notice.
t ml
http://www.domainregistry.ie/tech/dynamic-dns.h
Specifically, if your WinXP advanced DNS settings look like this, then just uncheck that box.
If the problem is the private IP's attempting to update DNS records then they have to have been nat'd or masqueraded in someway, so short of parsing EVERY DNS packet there is no way to tell since the source address will the user's public IP
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.
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
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.
With Win2k client you can:
:)~~
1. from start menu you choose
setting -> network and dial up connections
2. from network and dial up connections
right click local area connection properties
3. from local area connection properties
click internet protocol (TCP/IP) properties then click properties button below
4. from internet protocol (TCP/IP) properties
click the advance button
5. from advance TCP/IP settings
click DNS menu bar
6. from DNS sub menu
uncheck "register this connection's address in DNS"
and it is fixed
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/
AFACT, most Windows 2000 networks are still setup up the NT4 way -- using WINS for local name resolution and an external static DNS server.
Microsoft optimized the setting for their 'ideal' W2K/W2K/AD network, but that's only because they didn't bother putting some intelligence in the setting. DynDNS updates shouldn't be enabled unless the machine was being added to a ActiveDirectory domain.
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$
Blockpoth the quoster:
No. (Although using ".localdomain" doesn't suck as badly as naming your private network "slashdot.org" and assuming that your NATbox will prevent anyone from seeing this posturing..) In practice, using ".localdomain" probably won't break anything as a pseudo-TLD for an RFC 1918-conformant private IP space, presuming you're talking about a home network that's not going to have anything complex depending on absolutely strict, standards-compliant DNS behavior, but it's actually defined as a domain "having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use." I.e. for DNS purposes, the only .in-addr.arpa domain that should map into localdomain is 127.in-addr.arpa -- this is the class-A netblock for your loopback interface(s), which all have the form 127.#.#.#.
RFC 2606, "Reserved Top Level DNS Names", says that the TLD for a private network space should be one of the following:
- .example
- .test
- .invalid
(Note: there's no (technical) reason the TLD has to have three letters or less.)Need a UNIX/Linux/network guru in the Boulde