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


To: <plzak@arin.net>, <dnsop@cafax.se>
From: Daniel Senie <dts@senie.com>
Date: Tue, 07 Aug 2001 17:45:15 -0400
In-Reply-To: <000301c11f88$00c1d1c0$b3d9bbd4@plzak>
Sender: owner-dnsop@cafax.se
Subject: RE: comment on draft-ietf-dnsop-inaddr-required-02.txt

At 05:29 PM 8/7/01, Ray Plzak wrote:
>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.

And this is really a key point. End users should be allowed to use INADDR, 
if they want to use it. I've been wrestling with this for a while, in terms 
of what the draft needs to say here. I think a reasonable set of statements 
might be somthing along the lines of:

- those providing the address space MUST provide INADDR service, either 
themselves or by delegating zones to those using the space.

- those responsible for the end systems SHOULD set up PTR records for their 
hosts (or ask their provider to do it for them). The user is not required 
to have PTR records, if they so choose.

The draft already points out that using INADDR as a security mechanism is a 
bad idea. The general consensus in the room in Minneapolis was that we 
discourage any notion that there's security to be found in looking up PTR 
records followed by A records.

Thoughts?


> > -----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

-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com


Home | Date list | Subject list