[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: <dnsop@cafax.se>
From: "Ray Plzak" <plzak@arin.net>
Date: Tue, 7 Aug 2001 17:29:10 -0400
Importance: Normal
In-Reply-To: <200108071526.BAA21388@hadrian.staff.apnic.net>
Reply-To: <plzak@arin.net>
Sender: owner-dnsop@cafax.se
Subject: RE: comment on draft-ietf-dnsop-inaddr-required-02.txt

Providing servers for in-addr service is not the same as setting ptr records
for hosts.  I agree that the managers of space on bit boundaries, ie, /8,
/16, and /24 should provide servers for those below them.  The shorter the
prefix, the more important it is that the server be available.  However,
this in no way obligates the end host to use the service, it merely gives
that host the option of using it.

Ray

> -----Original Message-----
> From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se]On Behalf Of
> George Michaelson
> Sent: Wednesday, August 08, 2001 2:22 AM
> To: dnsop@cafax.se
> Subject: comment on draft-ietf-dnsop-inaddr-required-02.txt
>
>
>
>
> One non-security (well almost)  reason is that RIR and other
> allocatiors of large address space are required to list in-addr
> for the parent block, because thats how they delegate down to those
> who do chose to provide in-addr.
>
> So a consequence of not having in-addr for a given /prefix is
> that the parent /prefix-1 has to wear repeated requests for in-addr
> which it can't answer, and while this is not a big deal inside small
> allocations, for shorter prefix owners (or registries) the load
> can be excessive.
>
> Its a non-deliberate DoS effect that chokes semi-core DNS servers.
>
> We wind up doing nasty things like pretend-revoking the delegation
> so we can answer the much shorter NXDOMAIN instead of
> ourselves spinlocking
> to find an answer and timing out.
>
> So, I would welcome a requirement because it has the effect
> of reducing
> load on central infrastructure, and risks of DoS or
> service-quality loss
> to a third party when a large network space is live, and
> causing widley
> distributed places to attempt in-addr lookup.
>
> cheers
> 	-George


Home | Date list | Subject list