Subject: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-as112-dname-01.txt

From: Joe Abley <[email-masked]>
Date: Sat, 12 Oct 2013 17:39:15 -0400

Hi all,

In Berlin, Warren and I presented two approaches to expanding the AS112 project beyond that currently deployed (and described in RFC6304) with the primary goal of making it practical to add and remove zones from the system without requiring fine-grained management of a system that is only loosely-coordinated.

Our preference was to use DNAME, as described in draft-jabley-dnsop-as112-dname-00. We suggested to the room that what remained was to run some experiments to determine whether DNAME support was adequate for the purpose; if it turned out DNAME was not practical, our fallback plan was draft-wkumari-dnsop-omniscient-as112-03.

Geoff Huston and George Michaelson were kind enough to run an initial experiment this week to try and find problems with DNAME support in the wild. They did not find any; DNAME support (for the purposes of AS112) seems more than adequate. This document (below) includes a description of the experiment and the results.

We request that the chairs poll the working group and identify consensus (or not) to adopt this document.

Note that this document also recommends an update to 6304 (details of the proposed updates are included in an appendix). The authors are waiting on the reaction of the working group to this plan before preparing a candidate 6304bis (which I do not expect would take much time).

Thanks all,

Joe

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Subject: New Version Notification for draft-jabley-dnsop-as112-dname-01.txt
> Date: 12 October 2013 17:26:28 EDT
> To: George Michaelson <[email-masked]>, "George G. Michaelson" <[email-masked]>, Joe Abley <[email-masked]>, Brian Dickson <[email-masked]>, Warren Kumari <[email-masked]>
> 
> 
> A new version of I-D, draft-jabley-dnsop-as112-dname-01.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Filename:	 draft-jabley-dnsop-as112-dname
> Revision:	 01
> Title:		 AS112 Redirection using DNAME
> Creation date:	 2013-10-12
> Group:		 Individual Submission
> Number of pages: 23
> URL:             http://www.ietf.org/internet-drafts/draft-jabley-dnsop-as112-dname-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-jabley-dnsop-as112-dname
> Htmlized:        http://tools.ietf.org/html/draft-jabley-dnsop-as112-dname-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-jabley-dnsop-as112-dname-01
> 
> Abstract:
>   Many sites connected to the Internet make use of IPv4 addresses that
>   are not globally unique.  Examples are the addresses designated in
>   RFC 1918 for private use within individual sites.
> 
>   Devices in such environments may occasionally originate Domain Name
>   System (DNS) queries (so-called "reverse lookups") corresponding to
>   those private-use addresses.  Since the addresses concerned have only
>   local significance, it is good practice for site administrators to
>   ensure that such queries are answered locally.  However, it is not
>   uncommon for such queries to follow the normal delegation path in the
>   public DNS instead of being answered within the site.
> 
>   It is not possible for public DNS servers to give useful answers to
>   such queries.  In addition, due to the wide deployment of private-use
>   addresses and the continuing growth of the Internet, the volume of
>   such queries is large and growing.  The AS112 project aims to provide
>   a distributed sink for such queries in order to reduce the load on
>   the IN-ADDR.ARPA authoritative servers.  The AS112 project is named
>   after the Autonomous System Number (ASN) that was assigned to it.
> 
>   The AS112 project does not accommodate the addition and removal of
>   DNS zones elegantly.  Since additional zones of definitively local
>   significance are known to exist, this presents a problem.  This
>   document describes modifications to the deployment and use of AS112
>   infrastructure that will allow zones to be added and dropped much
>   more easily.
> 
> 
> 
> 
> 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: Tony Finch <[email-masked]>
Date: Mon, 14 Oct 2013 12:51:48 +0100

Joe Abley <[email-masked]> wrote:
>
> Geoff Huston and George Michaelson were kind enough to run an initial
> experiment this week to try and find problems with DNAME support in the
> wild. They did not find any; DNAME support (for the purposes of AS112)
> seems more than adequate. This document (below) includes a description
> of the experiment and the results.

We are using DNAME for some parts of the University of Cambridge's reverse
DNS. (See below for an example.) We have noticed one quirk and one problem
with this setup, and the problem isn't relevant to AS112. I think it would
make sense for the AS112 project to use DNAME.

The quirk occurs on Linux, where glibc moans in syslog that it doesn't
understand TYPE39 or DNAME (it varies depending on the version). Often the
messages will come from nscd. However the resolver nobly soldiers on and
handles the synthesized CNAME correctly. Example log message:

Oct 14 07:52:46 ppsw-33 nscd: gethostby*.getanswer:
	asked for "8.255.232.128.in-addr.arpa IN PTR", got type "DNAME"

The problem is that some mail servers check that the sender has a PTR
record, but choke on DNAME records in the answer. This is only a problem
if you have a server sending mail from an IP address with DNAME reverse
DNS, which is not the case for AS112.

; <<>> DiG 9.9.4rc1 <<>> +noauthority +nostats -x 128.232.232.252
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43769
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;252.232.232.128.in-addr.arpa. IN PTR

;; ANSWER SECTION:
232.232.128.in-addr.arpa. 1d IN DNAME 232.232.128.in-addr.arpa.cam.ac.uk.
252.232.232.128.in-addr.arpa. 1d IN CNAME 252.232.232.128.in-addr.arpa.cam.ac.uk.
252.232.232.128.in-addr.arpa.cam.ac.uk. 1d IN PTR gw-257.route-opress.net.cam.ac.uk.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: George Michaelson <[email-masked]>
Date: Tue, 15 Oct 2013 09:45:49 +1000

Worth logging a fault with the maintainers of the distro(s)? It seems to be
DNAME in reverse V6 may well be useful, albeit as you say not relevant to
AS112

On Mon, Oct 14, 2013 at 9:51 PM, Tony Finch <[email-masked]> wrote:

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