RE: [dnsop] Re: Review of draft-ietf-dnsop-inaddr-required

[Daniel Senie <[e-mail]>]

At 07:40 AM 1/30/2006, Brett Carr wrote:
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Stephane
> > Bortzmeyer
> > Sent: Monday, January 30, 2006 9:41 AM
> > To: Andrew Sullivan
> > Cc: [e-mail]
> > Subject: [dnsop] Re: Review of draft-ietf-dnsop-inaddr-required
> >
> > On Fri, Jan 27, 2006 at 05:32:57PM -0500,  Andrew Sullivan
> > <[e-mail]> wrote  a message of 54 lines which said:
> >
> > > The discussion in section 3 notes that there are a number of
> > > unfortunate consequences of missing IN-ADDR.  It seems to
> > me therefore
> > > that the recommendations in section 4 come out as a little too
> > > ambivalent: the suggestion appears to be that IN-ADDR is a
> > good thing,
> > > but that people shouldn't really use it.
> >
> > If I may, IMHO, the real issue is not wether PTR are good or
> > not but "Are people able to create and modify them?" and the
> > answer is NO for many cases.
>
>I would say in the majority of cases most end users (by this I mean
>businesses willing and able to run their own stable dns servers) are able to
>get reverse delegation from their network provider.
>What are these cases, maybe we can address the problem of what causes this
>inability to provide reverse delegation.
>
> > Because, even if you love PTR and you want to add them, you
> > depend on persons above (in the DNS reverse tree) you. I
> > deeply regret that the draft does not emphasize this problem
> > (may be because IETFers are typically working near the
> > ".arpa" apex and do not see the problems of the poor guys at
> > the bottom of the tree).
>
>Then maybe this problem also needs addressing in a separate draft, but I
>don't think that difficulty in obtaining PTR should stop us encouraging the
>use of it.

I concur on this. The reality is some regions of the world have 
little trouble with this, while others have a lot. Similarly some 
classes of connectivity have more trouble than others. That some 
large broadband providers, in their quest to race to the bottom of 
the pricing heap, have no margin left to service business customers 
adequately is a business problem, not a protocol problem.

The point of this document, or any other BCP-tracked document, is to 
recommend how things should be done, not to explain how to live with 
things as they are. BCP38 is a good example of this. There are lots 
of folks who still don't want to do ingress filtering, yet there are 
many who do it and it helps. Should we not have published BCP38 
because the recommendations require much cooperation to be effective 
or that some network operators won't cooperatively implement it? 
Having a BCP say "this is the preferred way to do something" would in 
this instance provide those not getting PTR record control from their 
ISPs with something to point to, saying "it'd be nice if you gave us 
a way to do PTR record work, so that we can comply with BCP xxx" or some such.


> >
> > Therefore, mandating the use of PTR records is a Bad Thing.
> >
>
>Well I would also say that maybe this document is badly titled as it doesn't
>seem to mandate the use of PTR so much as encourage it.

Please look at the actual title in the draft, and not the file name. 
The file naming is historical. The tone and scope has changed 
significantly since the first draft, to tone done the requirement aspect.


>Taken from the Introduction:
>
>"This document both encourages the presence of these mappings and
>discourages reliance on such mappings for security checks."
>
>
> > [I can add that getting a ip6.arpa or in-addr.arpa delegation
> > from above is more difficult in some parts of the world.
> > Mandating PTR records means banning Africa, for instance.]
> >
>
>Well I don't think any of us wants to see moves that would ban users In
>Africa from using the internet however I still say encouraging users to use
>reverse mappings where they are able to do so (especially in areas of
>Internet growth such as Africa) is an important message.
>
>Brett
>
>--
>Brett Carr                              RIPE Network Coordination Centre
>Systems Engineer -- Operations Group    Amsterdam, Netherlands
>GPG Key fingerprint = F20D B2A7 C91D E370 44CF  F244 B6A1 EF48 E743 F7D8
>
>
>.
>dnsop resources:_____________________________________________________
>web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
>mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html