Subject: RE: root server load and dynamic updates.

From: Bruce Campbell <[email-masked]>
Date: Tue, 23 May 2000 09:56:31 +1000 (EST)

On Mon, 22 May 2000, Randy Bush wrote:

randy> > A rough guess is that a fair bit is being trapped by intranets/downstream
randy> > nameservers, and that we're only seeing updates from the rare ones that
randy> > get past upstream filters.  Which is still a largish number.
randy> 
randy> i.e. the ones that are on the open internet and which accept unsecured
randy> dynamic update?

My apologies; I wasn't being precise with the last sentence.  The 'ones'
and 'bit' referred to are W2K clients that are sending dynamic updates to
given nameservers, some of which may accept dynamic updates.

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: "Stuart Kwan" <[email-masked]>
Date: Tue, 23 May 2000 19:00:22 -0700

In response to your two questions:

* No, W2K does not give up sending dynamic updates based on a previous
response.  It will retry failed updates on a periodic interval which
varies according to the service that is attempting the update.  (There
are two services in W2K - the DHCP client and Active Directory - that do
dynamic registrations.)

* We're investigating the TCP connection behavior in our lab right now.
I'll post an update when we've got results.

Cheers,
- Stuart

-----Original Message-----
From: Bruce Campbell [mailto:[email-masked]]
Sent: Sunday, May 21, 2000 8:52 PM
To: Stuart Kwan
Cc: [email-masked]
Subject: RE: root server load and dynamic updates.

On Fri, 19 May 2000, Stuart Kwan wrote:

skwan> The messages you are seeing come from computers running Windows
2000.

ok.

skwan> - W2K clients will attempt to add both A and PTR RRsets for the
skwan> configured names and addrs of a computer

That was assumed, however, the zones that I'm quoting logs for are only
for in-addr.arpas (ie, I'll only see PTR updates).

This also implies extra DNS queries to find the non-existence of
``my.private.tld.name.that.I.like.for.my.PC'' in a large number of
installations.  

( People will quite happily name their computer anything which makes
  sense to them, and, if they are in verbose mode, will argue with tech
  support when no-one else can resolve their name ;) )

skwan> - To perform the update, the client finds the enclosing zone of
the name
skwan> of the relevant RRset
skwan> - If the enclosing zone is the root zone '.', the client will NOT
send
skwan> the update

As shown previously, the SOA MNAME field of most ``large'' zones (com,
net, org, in-addr.arpa) is the same as the MNAME field in the parent
zone,
ie, a.root-servers.net .

skwan> - Update requests are directed at the SOA MNAME, per the dynamic
update
skwan> protocol

Question:

Is the dynamic update attempt done every time, or does it (win2k) give
up
trying to send future dynamic updates based on the previous responses ?

A simple solution would be to compare the MNAME field of the nearest
enclosing zone with the MNAME field of that zone's enclosing zone (and
so
forth to the root), and not attempting an update if these match.

However, this does not solve the TLD/RIR nameserver problem (ie, you'd
still be sending bogus update attempts to the nameservers of TLD
operators
etc etc).  Perhaps you should only be attempting dynamic updates if the
matching nameserver is X-hops away ?  (which makes certain assumptions
about the topology of ISP networks, etc etc)

Ideally, from an operator's POV, the behaviour is not on by default.

skwan> - The unknown record type query you are seeing is a TKEY query;
when a
skwan> W2K client receives REFUSED to an update request, it attempts to
skwan> negotiate security via
skwan> http://www.ietf.org/internet-drafts/draft-skwan-gss-tsig-05.txt

Going back to the verbose logs again, for every dynamic update (from a
W2K
client), ie:

May 22 10:53:59 nevyn named[29504]: unapproved update from
[203.117.103.254].214 4 for 117.203.in-addr.arpa

The following extra syslog entries:

May 22 10:54:00 nevyn named[29504]: IP/TCP connection from
[203.117.103.254].214 5 (fd 7)
May 22 10:54:01 nevyn named[29504]: IP/TCP connection from
[203.117.103.254].214 6 (fd 7)
May 22 10:54:03 nevyn named[29504]: IP/TCP connection from
[203.117.103.254].214 7 (fd 7)

are seen, which match the 'unknown RR type' entries in the really
verbose
logs.  

Previously I wasn't matching these up with a given connection, but each
unapproved dynamic update (from a W2K client) does indeed have 3 extra
TCP
connections consisting of the GSS TSIG updates. 

urm.

This does add a fair bit of overhead to a nameserver's operations.

Crosschecking with people who run both forward and reverse domains on
the
one nameserver, the same behaviour is exhibited on their nameserver for
each 'A' and 'PTR' update (ie, two UDP packets, 6 TCP connections).

Just possibly, I think W2K is a fair proportion of the extra load on
a.root-servers.net .  Perhaps NSI should consider changing the MNAME
field
in their zones to a seperate server until W2K's behaviour improves? ;)

Regards,

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