Subject: RE: root server load and dynamic updates.

From: "Stuart Kwan" <[email-masked]>
Date: Mon, 24 Apr 2000 08:25:55 -0700

In Windows 2000, if the dynamic update client discovers that the
enclosing zone is the root zone, it will (by default) NOT send the
dynamic update request.

However, if the name of the enclosing zone is at least one label long
(ie. "com", "edu", "arpa", etc) the client will send the update request.
The request will be sent to the primary name server that is named in the
SOA RR of the zone.

Levon and I would like to help investigate the possibility of Windows
2000's contributing to a load increase.  Who should we contact?

Cheers,
- Stuart

-----Original Message-----
From: Cricket Liu [mailto:[email-masked]]
Sent: Saturday, April 22, 2000 10:03 PM
To: Bruce Campbell; [email-masked]
Subject: Re: root server load and dynamic updates.

> Dynamic Updates on a 'orrible scale.  It appears to be that if a
windows
> 2000 machine cannot find its forward and reverse name to resolve
> correctly, it will send a dynamic update for the name to the nearest
found
> parent.
>
> Logically, this should *not* be the root nameservers.  Well,
logically,
> yes.  If the logical (listed) parents are not found, then I think it
walks
> back down the chain, and (possibly) to the roots.

Yup.  This is basically standard behavior for dynamic
update routines, whether Microsoft's or the ISC's:  find
the enclosing zone, locate its name servers and send
the dynamic update.

> As our[1] nameservers are authoritative for a few reverses[2], we tend
to
> see an awful lot of these dynamic updates, which show up as
'Unauthorised
> update' etc etc.
>
> Its the equivilant of a new-born baby waking up during its first
night,
> and immediately bawling down the phone to the deed poll office to
change
> their name.  Annoying, but it does save the parents the tramua of
naming
> the babe.

I've also heard rumors that these particular dynamic
updates are coming in over TCP, which would help
explain why they're so hard on name servers.  Can
anyone verify that?

cricket

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 25 Apr 2000 10:00:45 +1000 (EST)

On Mon, 24 Apr 2000, Stuart Kwan wrote:

skwan> In Windows 2000, if the dynamic update client discovers that the
skwan> enclosing zone is the root zone, it will (by default) NOT send the
skwan> dynamic update request.
skwan> 
skwan> However, if the name of the enclosing zone is at least one label long
skwan> (ie. "com", "edu", "arpa", etc) the client will send the update request.
skwan> The request will be sent to the primary name server that is named in the
skwan> SOA RR of the zone.

Ah, theres the sticker, ie:

com                     SOA     A.ROOT-SERVERS.NET hostmaster.internic.NET
net                     SOA     A.ROOT-SERVERS.net hostmaster.internic.net
org                     SOA     A.ROOT-SERVERS.NET hostmaster.internic.NET
in-addr.arpa            SOA     A.ROOT-SERVERS.NET hostmaster.INTERNIC.NET
193.in-addr.arpa        SOA     ns.ripe.net ops.ripe.net
203.in-addr.arpa        SOA     ns.apnic.net
please-read-TXT-record-of-this-zone-before-emailing-dns-admin.apnic.net (

skwan> Levon and I would like to help investigate the possibility of Windows
skwan> 2000's contributing to a load increase.  Who should we contact?

On our nameservers at least, its not a 'serious' traffic increase, so far.  
As they show up in the security logs, its more of a trivial annoyance than
anything, at the moment.

On the off chance that the above behaviour of Win2K may (eventually) be a
serious annoyance to the root servers, I'd request the following patches
in the next release/service patch to Win2K:

	Do not send dynamic updates to anything that is listed in the SOA
	record of a 'one label' zone (ie, com, net, org, all TLDs) .

	Do not send dynamic updates to anything that is listed in the SOA
	record of a two label zone in the CCTLDs (ie, com.au, co.nz,
	ac.uk).

	Do not send dynamic updates to anything that is listed in the SOA
	record of a three label zone in in-addr.arpa (ie,
	193.in-addr.arpa, 203.in-addr.arpa etc).

	Do not send dynamic updates to anything that is listed in the SOA
	record of a eight label zone in ip6.int or in6-addr.arpa
	(whichever).

Regards,

-- 
  Bruce Campbell <[email-masked]>                +61-7-3367-0490
                      Systems Administrator     Regional Internet Registry
    Asia Pacific Network Information Centre    For the Asia Pacific Region

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 26 Apr 2000 09:33:01 -0700

> in-addr.arpa    SOA    A.ROOT-SERVERS.NET   hostmaster.INTERNIC.NET

What would be the ramifications of setting MNAME to a bogus name?

If MNAME is only used for DDNS, then setting it to a bogus name would
prevent updates from hammering on A.

Obviously, any system can be misconfigured, so if using a bogus MNAMA
would prevent misconfigured systems from attempting to update these
zones, it might be worth exploring as a long-term option for all
affected zones. Like co.uk. could be configured with bogus MNAME data,
and so forth, if it works to prevent updates from misconfigured users.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Apr 2000 12:52:04 -0400

>and so forth, if it works to prevent updates from misconfigured users.

Two wrongs don't make a right. ;)  In other words, I wouldn't advocate
breaking the protocol to lessen the pain caused by broken implementations.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 27 Apr 2000 03:37:53 +1000

> and so forth, if it works to prevent updates from misconfigured users.

	No.  Then ALL the listed servers would be pounded apon as
	required by NOTIFY to support stealth servers.

	Mark
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 26 Apr 2000 10:02:15 -0700

> I wouldn't advocate breaking the protocol to lessen the pain caused
> by broken implementations.

Yah, I feel the same way about hacking up a solution like this. I don't
think that the implementation is "broken" though. A more accurate
definition would be that a large number of misconfigurations are
exposing weaknesses in the protocol, with the caveat being that the
aggressive directory/domain integration used in this particular product
is making it easier than ever for users to misconfigure their setup.

The same problems can occur with any DNS server that is misconfigured.
This hack is a possible solution to prevent these kinds of problems from
all of them.

The best long-term solution would be a RR or DHCP option that explicitly
stated which server(s) should get the updates, rather than relying on
the MNAME field. While MNAME works great for managed zones, it obviously
opens up some problems. Short term, one solution is bogus MNAME.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 26 Apr 2000 20:38:49 -0000

> What would be the ramifications of setting MNAME to a bogus name?

Better: A real name pointing to a different host, such as 127.0.0.1.

But I still haven't heard any evidence that this will noticeably affect
NSI's traffic. Post-hoc-propter-hoc garbage is not evidence. If there's
a torrent of dynamic updates, then that'll be obvious from a traffic
sample, so why does NSI say that it hasn't figured out the problem?

---Dan

---

From: Robert Elz <[email-masked]>
Date: Thu, 27 Apr 2000 08:46:03 +1000

Date:        26 Apr 2000 20:38:49 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | But I still haven't heard any evidence that this will noticeably affect
  | NSI's traffic. Post-hoc-propter-hoc garbage is not evidence. If there's
  | a torrent of dynamic updates, then that'll be obvious from a traffic
  | sample, so why does NSI say that it hasn't figured out the problem?

I suspect it isn't the traffic (yet anyway) that is the problem, but the
noise caused by the logs of all the unauthorised update attempts.   I see
the same thing for the com.au zone file.  The additional traffic doesn't
bother me as much, but the noise in the logs makes the logs useless
(how can I tell the difference between a real attempt to pervert the com.au
zone file, and just theses systems sending unwanted ddns to the wrong place)
and the load from actually doing the logging isn't negligible (which I could
avoid by turning it off - but then I lose other potentially useful log info
along with it).

kre