Subject: Re: root server load and dynamic updates.

From: Robert Elz <[email-masked]>
Date: Tue, 23 May 2000 16:09:56 +1000

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

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: Bruce Campbell <[email-masked]>
Date: Thu, 25 May 2000 12:29:12 +1000 (EST)

On Tue, 23 May 2000, Robert Elz wrote:

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

Going by inference of the updates we're seeing, you'd be getting
bogusname.com.au because people put in any name they please, ie:

177.162.111.202.in-addr.arpa.  20M IN PTR  server.master.lihua.
19.255.109.202.in-addr.arpa.  20M IN PTR  xmzct-lh88y28iu.domain.zxz.
22.130.118.211.in-addr.arpa.  20M IN PTR  twins.crusoeworld.
2.185.130.61.in-addr.arpa.  20M IN PTR  tc1.www.textclickcom.
114.27.100.202.in-addr.arpa.  20M IN PTR  mail.xa.xa.

-- 
  Bruce Campbell <[email-masked]>                +61-7-3367-0490
                      Systems Administrator     Regional Internet Registry
    Asia Pacific Network Information Centre    For the Asia Pacific Region

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 26 May 2000 09:08:39 +0200

>114.27.100.202.in-addr.arpa.  20M IN PTR  mail.xa.xa.
would a valid heuristic to adopt be to attempt the update in the forward 
zone first (subject to controls discussed earlier), and only attempt the 
reverse update if:

a) the update succeeded, or
b) the data was already in the forward zone?

(of course, also check that no PTR was present in the reverse zone in the 
last case.)

If someone configures mail.xa.xa as their name, tries to register that with 
the root nameservers, and gets rejected, there's very little reason to go 
try to install a pointer to the invalid name in the in-addr.arpa zone.

                  Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: "Cricket Liu" <[email-masked]>
Date: Fri, 26 May 2000 15:24:59 -0600

> try to install a pointer to the invalid name in the in-addr.arpa zone.

That would only work if the Windows 2000 DHCP server
were doing the updates for both the A and PTR RR.  The
default mode of operation has the DHCP server add the
PTR RR and the DHCP client add the A RR.

cricket

---

From: "Cricket Liu" <[email-masked]>
Date: Fri, 26 May 2000 15:29:55 -0600

> but I don't like all these bogus update requests either.

This could be difficult.  There aren't many filters available
that can tell the difference between an OPCODE=QUERY
DNS message and an OPCODE=UPDATE message.  Also,
I don't think pointing a client at a forwarder that is configured
not to forward updates is going to help, given that the
Microsoft and ISC dynamic update routines send updates
directly to the authoritative name servers for the enclosing zone,
not to the resolver's default name server.

cricket