Re: [DNSOP] WGLC: "Considerations for the use of DNS Reverse Mapping"

[Brian Dickson <[e-mail]>]

Andrew Sullivan wrote:
> Dear colleagues, 
>
> I received some time ago some comments off-list on the reverse-mapping
> considerations document.  I attempted unsuccessfully to convince the
> reviewer to send his substantive comments to the WG list, but he did
> not feel comfortable with that.  (He also provided a number of helpful
> editorial comments, which we incorporated in the most recent version
> of the draft.)
>
> I here will attempt to summarize my understanding of his comments.
>
>
> The reviewer takes exception to the suggestion that delegations in the
> forward zone should ideally have an entry in the reverse zone too.
> Instead, he suggests, that there be _at least one_ matching reverse;
> e.g.,
>
>          A (PTR (ipaddr))   == ipaddr                                           
> or       A (PTR (A (fqdn))) == A (fqdn)
>
> but not many more.  The reviewer argues that the draft should in fact
> argue against adding multiple ("more than a handful") PTR(s) for a
> given address.
>
>   

Ah. I think the issFrom [e-mail]  Sat Mar 29 13:31:39 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D20143A6F14;
	Sat, 29 Mar 2008 13:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.915
X-Spam-Level: 
X-Spam-Status: No, score=-100.915 tagged_above=-999 required=5
	tests=[AWL=-0.478, BAYES_00=-2.599, FH_RELAY_NODNS=1.451,
	HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id e9RKFsww6qc1; Sat, 29 Mar 2008 13:31:38 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E782B3A6F06;
	Sat, 29 Mar 2008 13:31:37 -0700 (PDT)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6BFCE3A6EFD
	for <[e-mail]>; Sat, 29 Mar 2008 13:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id lyUz0Lpqp3eX for <[e-mail]>;
	Sat, 29 Mar 2008 13:31:35 -0700 (PDT)
Received: from mx4.ca.afilias.info (vgateway.libertyrms.info [207.219.45.62])
	by core3.amsl.com (Postfix) with ESMTP id 660363A6EE6
	for <[e-mail]>; Sat, 29 Mar 2008 13:31:35 -0700 (PDT)
Received: from briand-vpn.int.libertyrms.com ([10.1.7.90])
	by mx4.ca.afilias.info with esmtp (Exim 4.22)
	id 1Jfhi9-0004BZ-Uq; Sat, 29 Mar 2008 16:31:33 -0400
Message-ID: <[e-mail]>
Date: Sat, 29 Mar 2008 16:31:33 -0400
From: Brian Dickson <[e-mail]>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Andrew Sullivan <[e-mail]>
References: <[e-mail]>	<[e-mail]>
	<[e-mail]>
In-Reply-To: <[e-mail]>
X-SA-Exim-Mail-From: [e-mail]
X-SA-Exim-Scanned: No; SAEximRunCond expanded to false
Cc: [e-mail]
Subject: Re: [DNSOP] WGLC: "Considerations for the use of
	DNS	Reverse	Mapping"
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]

Andrew Sullivan wrote:
> Dear colleagues, 
>
> I received some time ago some comments off-list on the reverse-mapping
> considerations document.  I attempted unsuccessfully to convince the
> reviewer to send his substantive comments to the WG list, but he did
> not feel comfortable with that.  (He also provided a number of helpful
> editorial comments, which we incorporated in the most recent version
> of the draft.)
>
> I here will attempt to summarize my understanding of his comments.
>
>
> The reviewer takes exception to the suggestion that delegations in the
> forward zone should ideally have an entry in the reverse zone too.
> Instead, he suggests, that there be _at least one_ matching reverse;
> e.g.,
>
>          A (PTR (ipaddr))   == ipaddr                                           
> or       A (PTR (A (fqdn))) == A (fqdn)
>
> but not many more.  The reviewer argues that the draft should in fact
> argue against adding multiple ("more than a handful") PTR(s) for a
> given address.
>
>   

Ah. I think the issue that (presumably) the original review had was, 
that if you have, say, 100 FQDNs,
all of which have:

    A ( fqdnXX ) == A.B.C.D
    (for all values of XX ranging from 00 to 99)

then the issue is, does there need to be 100 PTR records, where

    PTR ( A.B.C.D ) == fqdnXX
    (for all values of XX ranging from 00 to 99).

I would suggest that the forward/reverse validation embodied in this, 
could better be handled
from an operational perspective, with the following alternative solution:

    CNAME ( fqdnXX ) == fqdn00
    (for all values of XX ranging from 01 to 99)

and then only the one PTR record is needed to validate the 
forward/reverse universe:

    PTR ( A.B.C.D ) == fqdn00.

It's not perfect, but may be adequate for many of the uses of 
forward/reverse matching.

It also does a better job of embodying the *intent* of both PTR and 
CNAME, when there are many
domains served/hosted on a single IP address.

(I would suggest that anyone considering doing the CNAME exercise, do so 
with sub-domain entries
rather than with the entire domain, so that SOA information can be kept 
separate for each domain.
E.g. have a real SOA for subdomain25.example.com, and a CNAME for 
www.subdomain25.example.com
which points to www.example.com, rather than having 
subdomain25.example.com be a CNAME pointing
to example.com.)

> It was our (the editors') impression that the above is consistebt with
> what the draft actually says, but that it has a different emphasis.
> That is, we think the draft says that existing reverse data is
> generally good, and matching reverse is nice to have, but that you
> shouldn't take this too far.  We decided not to try to change this in
> the draft on the grounds of the support we had so far, but we're
> certainly open to changes if others think this message is garbled in
> the existing version of the draft.
>   

I think the language in the current draft does a good job of describing 
the general use and intent
behind its own recommendation, without delving into the minutia that 
having examples iterating
over many use cases would require.

I think in all cases, it is imperative that a solid understanding of the 
implications of design choices
exists, prior to embarking on implementing a given design. It is highly 
unlikely that a BCP can
do more than guide readers on the high-level issues, and the deeper 
understanding is the
responsibility of the reader, not the authors.

Brian Dickson
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop


ue that (presumably) the original review had was, 
that if you have, say, 100 FQDNs,
all of which have:

    A ( fqdnXX ) == A.B.C.D
    (for all values of XX ranging from 00 to 99)

then the issue is, does there need to be 100 PTR records, where

    PTR ( A.B.C.D ) == fqdnXX
    (for all values of XX ranging from 00 to 99).

I would suggest that the forward/reverse validation embodied in this, 
could better be handled
from an operational perspective, with the following alternative solution:

    CNAME ( fqdnXX ) == fqdn00
    (for all values of XX ranging from 01 to 99)

and then only the one PTR record is needed to validate the 
forward/reverse universe:

    PTR ( A.B.C.D ) == fqdn00.

It's not perfect, but may be adequate for many of the uses of 
forward/reverse matching.

It also does a better job of embodying the *intent* of both PTR and 
CNAME, when there are many
domains served/hosted on a single IP address.

(I would suggest that anyone considering doing the CNAME exercise, do so 
with sub-domain entries
rather than with the entire domain, so that SOA information can be kept 
separate for each domain.
E.g. have a real SOA for subdomain25.example.com, and a CNAME for 
www.subdomain25.example.com
which points to www.example.com, rather than having 
subdomain25.example.com be a CNAME pointing
to example.com.)

> It was our (the editors') impression that the above is consistebt with
> what the draft actually says, but that it has a different emphasis.
> That is, we think the draft says that existing reverse data is
> generally good, and matching reverse is nice to have, but that you
> shouldn't take this too far.  We decided not to try to change this in
> the draft on the grounds of the support we had so far, but we're
> certainly open to changes if others think this message is garbled in
> the existing version of the draft.
>   

I think the language in the current draft does a good job of describing 
the general use and intent
behind its own recommendation, without delving into the minutia that 
having examples iterating
over many use cases would require.

I think in all cases, it is imperative that a solid understanding of the 
implications of design choices
exists, prior to embarking on implementing a given design. It is highly 
unlikely that a BCP can
do more than guide readers on the high-level issues, and the deeper 
understanding is the
responsibility of the reader, not the authors.

Brian Dickson
_______________________________________________
DNSOP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsop