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

From: Petr Spacek <[email-masked]>
Date: Thu, 27 Aug 2015 12:39:01 +0200

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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bob Harold <[email-masked]>
Date: Thu, 27 Aug 2015 11:22:31 -0400

On Thu, Aug 27, 2015 at 6:39 AM, Petr Spacek <[email-masked]> wrote:

> Status:
> https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/
> 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:

-- 
Bob Harold

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Aug 2015 10:22:37 -0700

> I'm requesting a call for adoption of draft-spacek-dnsop-update-clarif.

i'm in favour, and will review.

-- 
Paul Vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 28 Aug 2015 09:09:54 +1000

> i'm in favour, and will review.

In favour, though it shouldn't be needed.  Reviewed early drafts.

We need a complementary draft to say that nodes should attempt to
update their PTR records.  Use TCP if they don't have key material
otherwise SIG(0) or TSIG.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 31 Aug 2015 17:44:49 -0400

Hi Petr,

I have reviewed this draft.

A couple of minor editorial nits aside, I think it does a good job at 
providing a solution to the problem it identifies.

[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.]

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.

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:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Sep 2015 08:18:37 +1000

In message <[email-masked]>, "Joe Abley" writ
> IN-ADDR.ARPA domain. The advice holds true for the whole namespace, so 

UPDATE is a general protocol.  You need to decide if you are updating
the data at the CNAME owner or the CNAME target.  There is no correct
thing to do in the general case.  

You almost certainly don't want to follow the CNAME in this case.

	update add example.net. 3600 CNAME example.com.

For this one you wouldn't want to follow the CNAME.

	update delete example.net. CNAME
	update add example.net. 3600 NS foo.example.com.

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

If you are updating the name associated with a machine you are starting
with a IP address and wanting to update the PTR record after following
the CNAME chain if any.  This is a specific case where you know that
you want to change the target of the CNAME chain if it is present.

> > Title:		Clarifications to the Dynamic Updates in the Domain Nam
> e 
> > System (DNS
> > UPDATE) specification

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Aug 2015 21:04:37 -0400

Dear colleagues,

On Mon, Aug 31, 2015 at 05:44:49PM -0400, Joe Abley wrote:

> namespace plus some conventions)

Loathe as I am to endure this again, the reverse mapping problems keep
cropping up, and I keep feeling like a bunch of distinctions in the
failed reverse-mapping-considerations draft [1] were helpful to making
some things clearer.

Am I the only one?  If not, please send your remarks to the effect
that at least something there was worth doing (and specify what it
was).  You can do it off list.  If I get something that seems like
encouragement rather than hellfire v2, I'll poke Daniel and see
whether we can at least make those parts live again.

[1] For those of you spared the last time,
https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06

-- 
Andrew Sullivan
[email-masked]