Subject: Re: [DNSOP] Requesting adoption of draft-spacek-dnsop-update-clarif

From: Petr Spacek <[email-masked]>
Date: Fri, 11 Sep 2015 07:20:31 +0200

Hi Joe,

On 31.8.2015 23:44, Joe Abley wrote:
> [You might consider using "initiator" rather than "requestor", incidentally; I
> think I first saw "initiator" and "responder" in one of Vixie's drafts, and I
> like them to describe the actors that engage in a single DNS transaction.]

Well, RFC 2136 is using term "requestor" and here I believe that it is a good
idea to use the very same term when clarifying the behavior.

> People are (I think) used to seeing CNAMEs in the "forward" namespace. People
> are apparently less familiar with them in the "v4 reverse" namespace (or else
> you wouldn't have been motivated to write this draft).
> 
> Since the core problem here is that people are not realising that there really
> is no "forward" and "reverse" namespace (there's just a single namespace plus
> some conventions) it seems slightly odd that this document explicitly
> addresses the problem with reference to the IN-ADDR.ARPA domain. The advice
> holds true for the whole namespace, so why restrict it?
> 
> I realise the specification in section 4 doesn't specify that it's only for
> use under the IN-ADDR.ARPA domain, but that's where the preamble leads you,
> and the example given in the first paragraph is still an IPv4 reverse one.

I wholeheartedly agree with you in this aspect. The clarification should not
be limited to in-addr.arpa at all. I'm just trying to find a balance between
the abstract description of the problem and the most prominent example of the
problem we see in practice (which might be easier to understand for implementers).

Here I'm certainly open to suggestions how to improve this:
Do you have any specific changes in mind? I would be happy to update the draft :-)

Would it help if we change the abstract from:

   This document clarifies interaction among Dynamic Updates in the
   Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation,
   and Secure Domain Name System (DNS) Dynamic Update in the presence of
   CNAME/DNAME redirections.

to something like this?

   This document clarifies interaction among Dynamic Updates in the
   Domain Name System (DNS UPDATE) and Secure Domain Name System (DNS)
   Dynamic Update in the presence of CNAME/DNAME redirections.
   Most prominent example of this situation is classless IN-ADDR.ARPA
   delegation.

Eh, I cannot say if the new text is significantly better or not but do not
have idea how to improve it even more.

Maybe the Introduction could paraphrase the Mark's e-mail from 01 Sep 2015
08:18:37 +1000. What about this text as replacement for whole Introduction?

--- Intro ---
This document clarifies interaction among Dynamic Updates in the
Domain Name System (DNS UPDATE) and Secure Domain Name System (DNS)
Dynamic Update in the presence of CNAME/DNAME redirections.

It was identified that common implementations using DNS update
protocol often ignore existence of CNAME/DNAME redirections and, as a
result, fail to update records if redirection is used.

DNS UPDATE is a general protocol.  The requestor needs to decide if he intends
to update the data at the CNAME/DNAME owner or the CNAME/DNAME target. There
is no correct thing to do in the general case. For example:

If the requestor is using a zone management tool he almost certainly don't
want to follow a CNAME if it is present.

On the other hand, if the requestor is updating the name associated with a
machine, he might be starting with a IP address and wanting to update the PTR
record after following the CNAME/DNAME chain (if any). This is a specific case
where the requestor knows that he wants to change the target of the
CNAME/DNAME chain if it is present.

[RFC2317] describes how to use the CNAME records in IN-ADDR.ARPA DNS
zones to split administrative control over IN-ADDR.ARPA data for
classless networks.  This is the most prominent example of situation where DNS
update requests need special handling described in this document.

Applicability:
This clarification is applicable to parties wanting to update records
in IN-ADDR.ARPA and other zones without changing existing CNAME/DNAME
redirections. This clarification is not applicable to cases where the
purpose of the DNS update is to change CNAME/DNAME redirection.

Any suggestions are more than welcome! Thank you for your time.

Petr Spacek

> In answer to the actual question you asked, I support adoption, and I'll
> support adoption again when the chairs actually ask for it, at which point I
> can review again if anybody wants me to :-)
> 
> 
> Joe
> 
> On 27 Aug 2015, at 6:39, Petr Spacek wrote:
> 
>> Dear DNSOP Chairs,
>>
>> I'm requesting a call for adoption of draft-spacek-dnsop-update-clarif.
>>
>> We did not have time allocated for discussing this in Prague but the draft is
>> so short and easy (to quote Mark's words: "blatantly obvious") that I do not
>> feel that postponing this till Yokohama is necessary.
>>
>> Thank you.
>> Petr Spacek
>>
>>
>> A new version of I-D, draft-spacek-dnsop-update-clarif-01.txt
>> has been successfully submitted by Petr Spacek and posted to the
>> IETF repository.
>>
>> Name:        draft-spacek-dnsop-update-clarif
>> Revision:    01
>> Title:        Clarifications to the Dynamic Updates in the Domain Name
>> System (DNS
>> UPDATE) specification
>> Document date:    2015-08-27
>> Group:        Individual Submission
>> Pages:        5
>> URL:
>> https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-01.txt
>> Status:        
>> https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/
>> Htmlized:       https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-spacek-dnsop-update-clarif-01
>>
>> Abstract:
>> This document clarifies interaction among Dynamic Updates in the
>> Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation,
>> and Secure Domain Name System (DNS) Dynamic Update in the presence of
>> CNAME/DNAME redirections.

-- 
Petr Spacek  @  Red Hat

---

From: Petr Spacek <[email-masked]>
Date: Fri, 11 Sep 2015 16:59:02 +0200

On 27.8.2015 17:22, Bob Harold wrote:
> On Thu, Aug 27, 2015 at 6:39 AM, Petr Spacek <[email-masked]> wrote:
> 
>> Dear DNSOP Chairs,
>>
>> Htmlized:
>> https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01
>> Diff:
>> Minor grammar suggestion - add "the" at three places:
> 
> -----Change
> 
>    A Requestor MUST resolve (canonicalize) the original owner name (e.g.
>    the one derived from an IPv4 address) to a canonical owner name
>    before constructing the Update Message.  The requestor MUST follow
>    whole chain of redirections until the terminal node of the chain is
>    reached and use canonical name found at the terminal node.
>    Implementations MUST detect infinite loops.
> 
>    Canonical owner name MUST be used instead of the original owner name
>    in the resulting Update Message:
> 
> ----to:
> 
>    A Requestor MUST resolve (canonicalize) the original owner name (e.g.
>    the one derived from an IPv4 address) to a canonical owner name
>    before constructing the Update Message.  The requestor MUST follow
>    the whole chain of redirections until the terminal node of the chain is
>    reached and use the canonical name found at the terminal node.
>    Implementations MUST detect infinite loops.
> 
>    The canonical owner name MUST be used instead of the original owner name
>    in the resulting Update Message:

Thanks, I've fixed these in Git. I would appreciate your comment on other
changes proposed for this document.

Have a nice day!

-- 
Petr Spacek  @  Red Hat