At 07:40 AM 1/30/2006, Brett Carr wrote:
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Stephane
> Bortzmeyer
> Sent: Monday, January 30, 2006 9:41 AM
> To: Andrew Sullivan
> Cc: [email protected]
> Subject: [dnsop] Re: Review of draft-ietf-dnsop-inaddr-required
>
> On Fri, Jan 27, 2006 at 05:32:57PM -0500, Andrew Sullivan
> <[EMAIL PROTECTED]> 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
