[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Bruce Campbell" <bruce.campbell@apnic.net>
Cc: <dnsop@cafax.se>
From: "Stuart Kwan" <skwan@Exchange.Microsoft.com>
Date: Tue, 23 May 2000 19:00:22 -0700
content-class: urn:content-classes:message
Sender: owner-dnsop@cafax.se
Thread-Index: Ab/DoIWx3ehE9z3NRA25xzTYbQRUVgBg6P7A
Thread-Topic: root server load and dynamic updates.
Subject: RE: root server load and dynamic updates.

Title: RE: root server load and dynamic updates.

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:bruce.campbell@apnic.net]
Sent: Sunday, May 21, 2000 8:52 PM
To: Stuart Kwan
Cc: dnsop@cafax.se
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 <bruce.campbell@apnic.net>                +61-7-3367-0490
                      Systems Administrator     Regional Internet Registry
    Asia Pacific Network Information Centre    For the Asia Pacific Region




Home | Date list | Subject list