To:
Bruce Campbell <bruce.campbell@apnic.net>, Robert Elz <kre@munnari.OZ.AU>
Cc:
dnsop@cafax.se
From:
Harald Alvestrand <Harald@Alvestrand.no>
Date:
Fri, 26 May 2000 09:08:39 +0200
In-Reply-To:
<Pine.BSF.4.21.0005251218120.901-100000@julubu.staff.apnic.net>
Sender:
owner-dnsop@cafax.se
Subject:
Re: root server load and dynamic updates.
At 12:29 25.05.2000 +1000, Bruce Campbell wrote:
>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.
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
Harald.Alvestrand@edb.maxware.no