Subject: [DNSOP] DNS updates and classless in-addr.arpa delegation/CNAMEs

From: Petr Spacek <[email-masked]>
Date: Wed, 03 Jun 2015 08:53:44 +0200

Hello,

I would like early feedback about following idea about interaction between DNS
updates (RFC 2136) and classless IN-ADDR.ARPA delegation (RFC 2317).

In short, the RFC 2317 tells me to fill reverse zone with CNAMEs pointing to
(potentially) some other zone.

At the same time, an attempt to add a PTR record to a node already containing
CNAME will fail, possibly without reporting an error to the requester. AFAIK
BIND 9.9 just prints an error to log but returns NOERROR to the client.

As a result, RFC 2317 breaks dynamic updates for classless reverse zones.

I'm going to sketch -00 draft which will attempt to address this by
client-side canonization:

The client should attempt to resolve whole chain of CNAME/DNAMEs from
1.2.0.192.in-addr.arpa down to terminal node and update the terminal node
instead of the original name.

Most interesting part of the text will be 'Security Considerations'
(considering signed updates).

I would welcome early feedback about the idea even before the -00 is published.

Thank you very much!

-- 
Petr Spacek  @  Red Hat

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Jun 2015 18:44:09 +1000

> As a result, RFC 2317 breaks dynamic updates for classless reverse zones.

No, it doesn't.  Add a appropriate prerequisite and you will a
error.

nxrrset owner cname 
add owner ptr hostname

A naive client won't work but RFC 2317 has been around for decades
now so cnames should be handled.

> instead of the original name.

You will get that as a side effect of working out where the zone
cut points are.

<soa,4.3.2.1.in-addr.arpa> will get back the cname chain (if any)
and the appropriate zone soa if rfc2308 is supported either in the
answer section or in the authority section.

> I would welcome early feedback about the idea even before the -00 is publishe

This shouldn't require a RFC as is it just apply exisiting RFC but
if it was to recommend that all nodes attempt to add PTR records
for themselves and described handling RFC 2317 as a senario it would
be more useful.  Similarly handling DNAME.

> Thank you very much!
> 
> -- 
> Petr Spacek  @  Red Hat
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Petr Spacek <[email-masked]>
Date: Mon, 29 Jun 2015 15:29:46 +0200

> now so cnames should be handled.

I wish it was true. I did some experiments and even latest versions of Windows
clients (8 + latest 10 beta) fail to take RFC 2317 into account and fail
miserably when attempting to update PTR records. This confirms rumors from
support people in the field.

nsupdate from BIND 9.9 is basically a low-level tool so it cannot be blamed
that it 'just fails' if the CNAME is present, but it also means that
'nsupdate' user has to implement own logic on top of it to handle RFC 2317. I
seriously doubt that anybody did that.

I feel that this effectively means that significant portion of PTR-updating
DNS clients does not work when RFC 2317 is used and this in my eyes justifies
a clarification.

> answer section or in the authority section.

I agree with this, but it is not enough, only a first step. Requestor also has
to replace original names with the canonicalized versions in prerequisite and
update sections of the Update Message otherwise the update will fail with
'out-of-zone' errors.

> be more useful.  Similarly handling DNAME.

Here is the first sketch. It does not propose any protocol changes, it is just
guidance for DNS UPDATE requestors.

This is my very first draft and I struggle with terminology, especially with
definition of canonicalization. Any feedback is more than welcome!

Petr Spacek  @  Red Hat

-------- Forwarded Message --------
Subject: New Version Notification for draft-spacek-dnsop-update-clarif-00.txt
Date: Mon, 29 Jun 2015 05:04:14 -0700
From: [email-masked]
To: Petr Spacek <[email-masked]>, Petr Spacek <[email-masked]>

A new version of I-D, draft-spacek-dnsop-update-clarif-00.txt
has been successfully submitted by Petr Spacek and posted to the
IETF repository.

Name:		draft-spacek-dnsop-update-clarif
Revision:	00
Title:		Clarifications to the Dynamic Updates in the Domain Name System (DNS
UPDATE) specification
Document date:	2015-06-29
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-00.txt
Status:         https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/
Htmlized:       https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-00

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.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 30 Jun 2015 09:55:57 +1000

Section 3 contains a obvious error

"192.0.2.1 -> 2.0.192.in-addr.arpa." should be
"192.0.2.1 -> 1.2.0.192.in-addr.arpa."