To:
Stuart Kwan <skwan@Exchange.Microsoft.com>
cc:
dnsop@cafax.se
From:
Bruce Campbell <bruce.campbell@apnic.net>
Date:
Mon, 22 May 2000 13:51:55 +1000 (EST)
In-Reply-To:
<19398D273324D3118A2B0008C7E9A569067DF1C8@SIT.platinum.corp.microsoft.com>
Sender:
owner-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