To:
Harald Tveit Alvestrand <Harald@Alvestrand.no>
cc:
dnsop@cafax.se
From:
Bruce Campbell <bruce.campbell@apnic.net>
Date:
Fri, 19 May 2000 16:00:42 +1000 (EST)
In-Reply-To:
<Pine.BSF.4.21.0005031542580.30019-100000@julubu.staff.apnic.net>
Sender:
owner-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