Subject: RE: root server load and dynamic updates.

From: "Stuart Kwan" <[email-masked]>
Date: Tue, 23 May 2000 19:09:39 -0700

Once the client has found the nearest enclosing zone, it goes no higher.
Therefore, I believe this condition is caused by clients configured with
"bogus.com.au" (or other non-existent) domain names, where "com.au" (or
other TLD) is the nearest enclosing zone.  You should be able to verify
this by looking at the names that clients are attempting to update, and
seeing if they are bogus or not.

I don't think ISPs would agree to filtering & forwarding, since it
limits the kind of service they can offer (ie. I would not be able to
run my own independent recursive DNS server, because the ISP would be
eating my recursion packets).

-----Original Message-----
From: Robert Elz [mailto:[email-masked]]
Sent: Monday, May 22, 2000 11:10 PM
To: Stuart Kwan
Cc: [email-masked]
Subject: Re: root server load and dynamic updates. 

    Date:        Fri, 19 May 2000 08:46:37 -0700
    From:        "Stuart Kwan" <[email-masked]>
    Message-ID:
<[email-masked]
m>

Stuart, I'm confused by this part ...

  | - To perform the update, the client finds the enclosing zone of the
name
  | of the relevant RRset

In general, what's being done (modulo whatever security issues arise)
seems like it ought to be fine ... but I don't understand how those of
us here who are noticing these queries and their affects are actually
being
hit.

eg: I run the SOA.MNAME server for com.au (munnari.oz.au) and I see lots
of
these update attempts in the com.au zone.

But that makes no sense - surely the client is going to be random.com.au
and should be finding the SOA.MNAME for random.com.au instead of for
com.au ??   How does it ever get that extra level up the tree?   The
same
would apply (even more so) to the .com servers where only NS type
delegations
exist (there are a few A and MX only 'delegations' in com.au where the
nearest MNAME would be the one in com.au).

What is the mechanism that the clients are using that is directing them
to upper level servers?

Or is this only happening when someone configures their client as being
bogus.com.au (something which doesn't exist) where the client then
discovers
com.au as the nearest enclosing domain?

Should we be encouraging ISPs to filter DNS traffic of their clients
onto
the net, and require clients to use an ISP provided forwarder (which
would
not forward any update requests) ?   That isn't something I'd like to
see,
but I don't like all these bogus update requests either.

kre

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 24 May 2000 10:55:59 -0700

> Stuart Kwan wrote:

> I believe this condition is caused by clients configured with
> "bogus.com.au" (or other non-existent) domain names, where "com.au"
> (or other TLD) is the nearest enclosing zone.

There are a lot of issues at play here, but the primary super-issue that
we're talking about here is PTR records and not A records. Given the
following, it's somewhat likely that excessive updates are more of a
problem for PTR records than for A records:

  1) Most Internet-connected networks that are less than 2 years old
     will have CIDR address blocks.

  2) Windows 2000's DDNS does not support classless delegation, as
     per the resource kit documentation.

  3) The Active Directory wizard does not create reverse lookup zones
     automatically.

My bet is that these elements conspire heavily to cause a significant
amount of the registrations to get forwarded up the in-addr.arpa. tree.
For example, if a network has a /26 mask, the registering systems are
GUARANTEED to send the UPDATE messages to the ISPs authoritative servers
(if they exist). Or in another case, if the organization is using a /24
but has not manually created the zone, then those requests will also go
up the tree.

I would recommend two actions here. The first would be a comparison of
the update requests being sent to a.root-servers.net to see how many of
them are for bogus.com. versus how many are for in-addr.arpa. space,
just to verify/disprove this suspicion. The second would be some kind of
effort to minimize the likelihood of the in-addr.arpa. walks. It may be
that you can minimize a lot of the load by simply exlcluding that domain
the same as you exclude root.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com