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

From: Joe Abley <[email-masked]>
Date: Fri, 28 Jun 2013 18:32:13 -0400

Hi all,

As promised, here's a draft which describes the alternate approach (alternate to the omniscient, custom-code route that our other document proposes) of using DNAME to extend AS112 service.

<sales pitch>
  This one has the side-effect of supporting DNSSEC-validatable redirection to AS112 nodes!
</sales pitch>

:-)

Joe

Begin forwarded message:

> From: "[email-masked]" <[email-masked]>
> Subject: New Version Notification for draft-jabley-dnsop-as112-dname-00.txt
> Date: 28 June 2013 18:23:33 EDT
> To: Joe Abley <[email-masked]>, Brian Dickson <[email-masked]>
> 
> 
> A new version of I-D, draft-jabley-dnsop-as112-dname-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Filename:	 draft-jabley-dnsop-as112-dname
> Revision:	 00
> Title:		 AS112 Redirection using DNAME
> Creation date:	 2013-06-28
> Group:		 Individual Submission
> Number of pages: 20
> URL:             http://www.ietf.org/internet-drafts/draft-jabley-dnsop-as112-dname-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-jabley-dnsop-as112-dname
> Htmlized:        http://tools.ietf.org/html/draft-jabley-dnsop-as112-dname-00
> 
> 
> 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.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Chris Thompson <[email-masked]>
Date: 29 Jun 2013 21:50:17 +0100

On Jun 28 2013, Joe Abley wrote:

>Hi all,
>
>As promised, here's a draft which describes the alternate approach
>(alternate to the omniscient, custom-code route that our other document
>proposes) of using DNAME to extend AS112 service.

This approach does seem quite attractive.

A point that maybe needs mention in section 6, in the context of caching.
For a DNAME-unaware resolver, this depends on the TTL of the synthesised
CNAME. RFC 2672 (Aug 1999) specified that this should be zero, and this
wasn't officially changed until RFC 6672 (June 2012) re-specified it as
a copy of the TTL of the DNAME. It perhaps ought to be emphasised that
the authoritative nameservers for zones containing DNAMEs referencing
EMPTY.AS112.ARPA should be using the later specification.

Does one have to worry about DNAME-broken resolvers? That is, ones that
choke on the presence of the DNAME in the answer and never get as far as
looking at the synthesised CNAME, effectively treating it as a SERVFAIL.
We certainly had some problems of that sort back in early 2011 when
we started using DNAMEs for reverse lookups of IPv4 addresses in
128.232.128.0/17. It's the reason why for 128.232.233.0/24 we use
256 CNAMEs rather than one DNAME.

>  This one has the side-effect of supporting DNSSEC-validatable redirection to AS112 nodes!

If the DNAME is signed, what effect is that going to have on overriding
local definitions of the redirected names (as in BIND's "automatic empty
zones")?

Of course if the scheme goes ahead, EMPTY.AS112.ARPA itself becomes an
obvious candidate for such a local definition as well.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.