RE: root server load and dynamic updates.

["Stuart Kwan" <skwan@Exchange.Microsoft.com>]

Title: RE: root server load and dynamic updates.

Bruce,

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

- W2K clients will attempt to add both A and PTR RRsets for the configured names and addrs of a computer
- To perform the update, the client finds the enclosing zone of the name of the relevant RRset
- If the enclosing zone is the root zone '.', the client will NOT send the update
- Update requests are directed at the SOA MNAME, per the dynamic update protocol
- We add the "NONE CNAME" conditional when updating a non-CNAME RRset to avoid a silent failure when attempting to update a name that already has a CNAME RRset (see RFC 2136 section 3.4.2.2)

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

Cheers,
- Stuart

-----Original Message-----
From: Bruce Campbell [mailto:bruce.campbell@apnic.net]
Sent: Thursday, May 18, 2000 11:01 PM
To: Harald Tveit Alvestrand
Cc: dnsop@cafax.se
Subject: Re: root server load and dynamic updates.

On Tue, 9 May 2000, Bruce Campbell wrote:

bc> On Tue, 2 May 2000, Harald Tveit Alvestrand wrote:
bc>
bc> Harald> A suitable experiment would be to configure one of the
bc> Harald> major zones with an MNAME pointing to a DNS server that is
bc> Harald> not a listed NS server for the zone, but has plenty of
bc> Harald> instrumentation attached to it to figure out who is doing
bc> Harald> what, and why. (And which logs to a different fileset!)
bc>
bc> Harald> If the load stays on the operational root, we know that
bc> Harald> Win2K DDNS is NOT the problem.
bc>
bc> As of next reload (~5 minutes), the MNAME field (and only the MNAME, not
bc> the serial) of our zones will refer to a different host.  This will be
bc> left in place for a week to see what appears in the logs of that host.

The host 'nevyn.apnic.net' was listed in the MNAME field of all of the
APNIC zones.  This host does not appear in the NS list of the APNIC zones.

For the zones which had their SOA serial updated under normal operations,
the flow of dynamic updates shifted to the above host.

For the zones which did not have their SOA serial updated (ie, they
remained static), the flow of dynamic updates *mostly* stayed with the
previous instance of the MNAME field (ns.apnic.net).

( Note that most of the APNIC zones have substantial time values in the
  SOA records, which means that DNS caching is also an issue here )

APNIC has not done any further investigation into the OSs of the hosts
sending in these dynamic updates, beyond noting that a reasonable number
appear to be originating from dialup hosts (based on traceroutes and last
hop delay times).

Summary:

        Something, or multiple somethings with the same behaviour
        patterns, is sending dynamic updates to the server listed in the
        MNAME attribute of the SOA record of the first-found parent zone.

        This appears to have a growing install base, and does appear to be
        *contributing* to a higher-than-expected increase in DNS queries.

Looking at an example query:

        datagram from [203.116.159.132].1224, fd 22, len 110
        ns_req(from [203.116.159.132].1224)
        ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 2068
        ;; flags:; ZONE: 1, PREREQUISITE: 0, UPDATE: 2, ADDITIONAL: 0
        ;;      116.203.in-addr.arpa, type = SOA, class = IN
        190.159.116.203.in-addr.arpa.  0S ANY PTR  190.159.116.203.in-addr.arpa.
        190.159.116.203.in-addr.arpa.  20M IN PTR  OA.oa.citidexa.com.
        req_update: section ZONE, count 1
        findzone(dname=116.203.in-addr.arpa, class=1, depth=0, zonelist=0x8045af0,
        maxzones=1025)
        findzone: returning 1 match(es)
        unapproved update from [203.116.159.132].1224 for 116.203.in-addr.arpa
        free_rrecp: update transaction succeeded, cleaning up
        ns_req: answer -> [203.116.159.132].1224 fd=22 id=2068 size=110

The parent zone is 116.203.in-addr.arpa .  The zone mentioned in the
above, 'citidexa.com', does not exist in the InterNIC database (maybe it
did at one time?) .  The update requested (203.116.159.190) is not the
same as the source (203.116.159.132).  The name in the request also
appears (from the same source, about 10 seconds later) for:

        178.159.116.203.in-addr.arpa.  20M IN PTR  OA.oa.citidexa.com.

Assumption here is perhaps a default ISP install setting the same name?

Curiously, there appear to be two distinct patterns.  The second pattern:

        datagram from [211.115.66.30].1835, fd 22, len 126
        ns_req(from [211.115.66.30].1835)
        ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 50
        ;; flags:; ZONE: 1, PREREQUISITE: 1, UPDATE: 2, ADDITIONAL: 0
        ;;      115.211.in-addr.arpa, type = SOA, class = IN
        30.66.115.211.in-addr.arpa.  0S NONE CNAME  30.66.115.211.in-addr.arpa.
        30.66.115.211.in-addr.arpa.  0S ANY PTR  30.66.115.211.in-addr.arpa.
        30.66.115.211.in-addr.arpa.  20M IN PTR  JEFF.HYDRA.finaldata.com.
        req_update: section ZONE, count 1
        findzone(dname=115.211.in-addr.arpa, class=1, depth=0, zonelist=0x8045af0,
        maxzones=1025)
        findzone: returning 1 match(es)
        unapproved update from [211.115.66.30].1835 for 115.211.in-addr.arpa

The 'NONE CNAME' conditional is interesting.  Also, this originates from
the same IP as the update requested (211.115.66.30).

Finally, we have the unknown record type (WINS?), ie:

        ns_req(from [203.116.159.132].1225)
        ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4320
        ;; flags:; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
        ;;      962072674322-3, type = 249, class = IN
        962072674322-3.         0S ANY 249      \#(             ; unknown RR type
                03 67 73 73 09 6d 69 63 72 6f 73 6f 66 74 03 63 ; .gss.microsoft.c
                6f 6d 00 39 24 cf 5a 39 26 20 da 00 03 00 00 00 ; om.9$.Z9& ......
                25 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 b2 00 ; %NTLMSSP........
                50 03 00 03 00 22 00 00 00 02 00 02 00 20 00 00 ; P...."....... ..
                00 4f 41 4f 41 30 00 00 )                       ; .OAOA0..
        FORMERR Query header counts wrong
        ns_req: answer -> [203.116.159.132].1225 fd=7 id=4320 size=12

Have I missed anything?

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