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

From: Joe Abley <[email-masked]>
Date: Wed, 6 Nov 2013 16:46:29 -0800

Hi all,

The authors would very much appreciate people here casting their eye over this text, and providing feedback on (a) clarity of the text and (b) technical viability of the approach.

Thanks,

Joe

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-ietf-dnsop-as112-dname-00.txt
> Date: 6 November 2013 at 10:58:36 PST
> To: Joe Abley <[email-masked]>, George G. Michaelson <[email-masked]>, George Michaelson <[email-masked]>, Warren Kumari <[email-masked]>, Brian Dickson <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-dnsop-as112-dname-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Filename:	 draft-ietf-dnsop-as112-dname
> Revision:	 00
> Title:		 AS112 Redirection using DNAME
> Creation date:	 2013-11-05
> Group:		 dnsop
> Number of pages: 23
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-dnsop-as112-dname-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-dnsop-as112-dname
> Htmlized:        http://tools.ietf.org/html/draft-ietf-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.
> 
> 
> 
> 
> 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: Warren Kumari <[email-masked]>
Date: Sun, 17 Nov 2013 19:01:26 -0300

Hi all,

So, we got some good review and feedback on this from Tony Finch, anyone else?

We feel that we received  sufficient discussion on the two inputs to this draft ( draft-wkumari-dnsop-omniscient-as112, draft-jabley-dnsop-as112-dname-01 ) that we are requesting WGLC.

W

On Nov 6, 2013, at 9:46 PM, Joe Abley <[email-masked]> wrote:

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

It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams

---

From: "John Levine" <[email-masked]>
Date: 18 Nov 2013 22:53:23 -0000

>So, we got some good review and feedback on this from Tony Finch, anyone else?

I read the draft, and as a spec it looks fine to me.  Once there are a
few empty.as112.arpa servers, you can send any branch of the DNS to
oblivion by pointing a DNAME at them.  I have 2 1/2 questions:

* Anyone can point a DNAME to empty.as112.arpa, not just subtrees of
rDNS.  Is that a security issue?

* I don't know what fraction of the Internet's DNS caches understand
DNAME and will synthezize responses from a cached DNAME.  The ones
that don't will presumably continue to hammer on the server(s) with
the DNAMEs.  Is that a performance or security issue?

* (the half question) Since DNAME only redirects names below the DNAME
and not the name itself, something a lot of people don't seem to
understand very well,* should the document offer any advice about what
else you might want to put at the name with the DNAME?

R's,
John

* - see the .CAT TLD for an example

---

From: Joe Abley <[email-masked]>
Date: Mon, 18 Nov 2013 18:09:50 -0500

Hi John,

> rDNS.  Is that a security issue?

I thought of it as a feature. AS112 is for everyone, not just IANA! :-)

> the DNAMEs.  Is that a performance or security issue?

See the appendix regarding experimental indications regarding DNAME support in the world (as far as we need it, e.g. using synthesised CNAMEs or understanding DNAMEs).

I don't think I quite see what you're getting at, though. Could you expand a little on the potential you see for increased traffic on authority servers?

> else you might want to put at the name with the DNAME?

That's an interesting point. For the reverse tree uses of AS112 we don't care, since the redirection point is never a well-formed QNAME in the reverse/1034 sense. What advice do you think is pertinent?

Joe

---

From: John R Levine <[email-masked]>
Date: Mon, 18 Nov 2013 20:40:41 -0500 (EST)

> I thought of it as a feature. AS112 is for everyone, not just IANA! :-)

Well, yes, but I'm trying to think of a bad guy who wants to hide part of 
his malware factory with split horizon or something.

>> DNAME and will synthezize responses from a cached DNAME. ...
>
> I don't think I quite see what you're getting at, though. Could you 
> expand a little on the potential you see for increased traffic on 
> authority servers?

The study in the appendix checked whether DNAME would break stuff, but 
unless I'm missing something, it didn't try to tell whether the client 
caches used the DNAME or the synthesized CNAME.  If it uses the DNAME, 
subsequent traffic from that cache for other addresses in the redirected 
subtree will go to empty.as112.arpa, more or less the same as it does now 
with the NS redirection, and the redirecting server will see less traffic. 
But for caches that don't understand DNAME, you'll get just as much 
traffic at the redirecting server, and then an equal additional amount to 
as112 via the synthesized CNAME to the empty.as112.arpa server.

Like I said, I don't know in practice what fraction of the world's DNS 
goes through caches that understand DNAME and what fraction doesn't. 
It's more complex than just counting the caches, since some caches like 
Google's 8.8.8.8 (which I'm fairly sure does DNAME properly) handle orders 
of magnitude more than little caches on small private networks.

> That's an interesting point. For the reverse tree uses of AS112 we don't 
> care, since the redirection point is never a well-formed QNAME in the 
> reverse/1034 sense. What advice do you think is pertinent?

If you redirect something that's not the middle of an rDNS name, remember 
that the name itself will not be redirected, so if you expect a lot of 
queries for the name at the redirection point, it won't help.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.