From bortzmeyer at nic.fr  Thu Apr 21 18:50:06 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Thu, 21 Apr 2016 20:50:06 +0200
Subject: [as112-ops] Advice requested on a proposal to delegate .local to
	AS112
Message-ID: <20160421185006.GA5455@laperouse.bortzmeyer.org>

Warning: I'm not an AS 112 operator and, therefore, I'm not on this
list. Please keep a copy of your emails to me (the list archives are
not public).

In the Internet-Draft "Using DNAME in the root for the delegation of
special-use TLDs"
<https://tools.ietf.org/html/draft-bortzmeyer-dname-root>, there is a
proposal to delegate heavy-use non-existing TLD like .local to the new
AS 112. Obviously, the advice of operators of the new AS 112 is very
important. So, please, if you approve or disapprove this idea, speak
now.


From cpetrie at ripe.net  Thu Apr 21 19:45:38 2016
From: cpetrie at ripe.net (Colin Petrie)
Date: Thu, 21 Apr 2016 21:45:38 +0200
Subject: [as112-ops] [gii-ops] Advice requested on a proposal to
 delegate .local to AS112
In-Reply-To: <20160421185006.GA5455@laperouse.bortzmeyer.org>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
Message-ID: <57192DE2.2000908@ripe.net>

On 21/04/16 20:50, Stephane Bortzmeyer wrote:
> In the Internet-Draft "Using DNAME in the root for the delegation of
> special-use TLDs"
> <https://tools.ietf.org/html/draft-bortzmeyer-dname-root>, there is a
> proposal to delegate heavy-use non-existing TLD like .local to the new
> AS 112. Obviously, the advice of operators of the new AS 112 is very
> important. So, please, if you approve or disapprove this idea, speak
> now.

My questions are:

*) How well deployed is RFC7535 (and the corresponding implementation
guidance in RFC7534)?

*) How do we measure its deployment? Atlas probes, open resolver scans, etc.

*) What is the criteria to declare the new AS112 worthy of having real
things delegated to it? I'm not aware of any existing delegations.
Please correct me if I'm wrong.

(And as an AS112 w/RFC7535 operator, we don't get delegated DNS traffic
to the new prefixes, last time I looked (a few months ago))

Cheers,
Colin

-- 
Colin Petrie
Systems Engineer
RIPE NCC

From clement at cavadore.net  Thu Apr 21 21:33:37 2016
From: clement at cavadore.net (Clement Cavadore)
Date: Thu, 21 Apr 2016 23:33:37 +0200
Subject: [as112-ops] Advice requested on a proposal to delegate .local
 to AS112
In-Reply-To: <20160421185006.GA5455@laperouse.bortzmeyer.org>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
Message-ID: <1461274417.12327.49.camel@puisard.hivane.net>

Hi Stephane,

I think that this is quite the aim of AS112 servers !
I approve then, and I'd be happy, as an operator, to handle those
requests :)

Regards,
-- 
Cl?ment Cavadore
Hivane

On Thu, 2016-04-21 at 20:50 +0200, Stephane Bortzmeyer wrote:
> Warning: I'm not an AS 112 operator and, therefore, I'm not on this
> list. Please keep a copy of your emails to me (the list archives are
> not public).
> 
> In the Internet-Draft "Using DNAME in the root for the delegation of
> special-use TLDs"
> <https://tools.ietf.org/html/draft-bortzmeyer-dname-root>, there is a
> proposal to delegate heavy-use non-existing TLD like .local to the new
> AS 112. Obviously, the advice of operators of the new AS 112 is very
> important. So, please, if you approve or disapprove this idea, speak
> now.
> 
> _______________________________________________
> as112-ops mailing list
> as112-ops at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/as112-ops



From wfms at ottix.net  Thu Apr 21 19:56:17 2016
From: wfms at ottix.net (William Sotomayor)
Date: Thu, 21 Apr 2016 15:56:17 -0400 (EDT)
Subject: [as112-ops] [gii-ops] Advice requested on a proposal to
 delegate .local to AS112
Message-ID: <alpine.DEB.2.20.1604211552350.3587@iskra.ottix.net>


>On 21/04/16 20:50, Stephane Bortzmeyer wrote:
>> In the Internet-Draft "Using DNAME in the root for the delegation of
>> special-use TLDs"
>> <https://tools.ietf.org/html/draft-bortzmeyer-dname-root>, there is a
>> proposal to delegate heavy-use non-existing TLD like .local to the new
>> AS 112. Obviously, the advice of operators of the new AS 112 is very
>> important. So, please, if you approve or disapprove this idea, speak
>> now.
>
>My questions are:
>
>*) How well deployed is RFC7535 (and the corresponding implementation
>guidance in RFC7534)?

I've not yet done a table survey to see how well RFC7534, but it's close 
to time to get doing it.  But last I saw, it wasn't well deployed.

>*) How do we measure its deployment? Atlas probes, open resolver scans, 
>etc.

Currently in progres is an open resolver scan, so results are just about 2 
weeks away.

>*) What is the criteria to declare the new AS112 worthy of having real
>things delegated to it? I'm not aware of any existing delegations.
>Please correct me if I'm wrong.
>
>(And as an AS112 w/RFC7535 operator, we don't get delegated DNS traffic
>to the new prefixes, last time I looked (a few months ago))

Therein lies the rub.  I'm not sure there's a 1:1 uptake between RFC7534 
and the RFC it replaced.

As for DNAME, I don't see much in that regard either.

wfms

From jabley at hopcount.ca  Fri Apr 22 02:28:51 2016
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 21 Apr 2016 22:28:51 -0400
Subject: [as112-ops] [gii-ops] Advice requested on a proposal to
 delegate .local to AS112
In-Reply-To: <alpine.DEB.2.20.1604211552350.3587@iskra.ottix.net>
References: <alpine.DEB.2.20.1604211552350.3587@iskra.ottix.net>
Message-ID: <etPan.57198c63.d3f4861.ced9@scallop.hopcount.ca>

On 21 April 2016 at 20:24:10, William Sotomayor (wfms at ottix.net) wrote:

>*) How well deployed is RFC7535 (and the corresponding implementation?
>guidance in RFC7534)??

I've not yet done a table survey to see how well RFC7534, but it's close?
to time to get doing it. But last I saw, it wasn't well deployed.?
How did you measure it?

When you say it's not well-deployed, are you talking about the number of nodes supporting blackhole.as112.arpa, or the number of nodes supporting v6 transport for prisoner, blackhole-1 and blackhole-2, or something else?

>*) How do we measure its deployment? Atlas probes, open resolver scans,?
>etc.?

Currently in progres is an open resolver scan, so results are just about 2?
weeks away.?
I'd be interested in learning more about your methodology.

>*) What is the criteria to declare the new AS112 worthy of having real?
>things delegated to it? I'm not aware of any existing delegations.?
>Please correct me if I'm wrong.?
The new AS112 presumably has the same number of things delegated to it, although lame delegation are possible (and no doubt detectable, if you receive the traffic).

The only thing that changed for the delegation AS112 service was the addition of AAAA RRs for prisoner, blackhole-1 and blackhole-2.

The only zone ever intended to be delegated to blackhole.as112.arpa is empty.as112.arpa. That's the domain name that zone administrators wanting to sink traffic using DNAME would redirect to.

>(And as an AS112 w/RFC7535 operator, we don't get delegated DNS traffic?
>to the new prefixes, last time I looked (a few months ago))?
I'm not sure what that means. If you announce 2620:4f:8000::/48 you don't see traffic at ::1, ::6 and ::42? Or something else?

Therein lies the rub. I'm not sure there's a 1:1 uptake between RFC7534?
and the RFC it replaced.?
I'm not sure exactly what that means, either. What would uptake for 7534 look like? More queries? Use of v6 for nameservers that didn't previously have AAAAs? Queries to blackhole.as112.arpa? All of the above?

As for DNAME, I don't see much in that regard either.?
Do you mean you aren't seeing any queries for empty.as112.arpa? Or you're not aware of anybody having installed a DNAME to empty.as112.arpa?



Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/mailman/private/as112-ops/attachments/20160421/d72bb1ec/attachment.html>

From cpetrie at ripe.net  Fri Apr 22 09:06:59 2016
From: cpetrie at ripe.net (Colin Petrie)
Date: Fri, 22 Apr 2016 11:06:59 +0200
Subject: [as112-ops] [gii-ops] Advice requested on a proposal to
 delegate .local to AS112
In-Reply-To: <etPan.57198c63.d3f4861.ced9@scallop.hopcount.ca>
References: <alpine.DEB.2.20.1604211552350.3587@iskra.ottix.net>
 <etPan.57198c63.d3f4861.ced9@scallop.hopcount.ca>
Message-ID: <1118a698-313a-d888-2f9b-f09cd2585ff5@ripe.net>

On 22/04/16 04:28, Joe Abley wrote:
>> >*) What is the criteria to declare the new AS112 worthy of having real 
>> >things delegated to it? I'm not aware of any existing delegations. 
>> >Please correct me if I'm wrong. 
> 
> The new AS112 presumably has the same number of things delegated to it,
> although lame delegation are possible (and no doubt detectable, if you
> receive the traffic).

I used the wrong word. DNAMEs, not delegations.

>> >(And as an AS112 w/RFC7535 operator, we don't get delegated DNS traffic 
>> >to the new prefixes, last time I looked (a few months ago)) 
> 
> I'm not sure what that means. If you announce 2620:4f:8000::/48 you
> don't see traffic at ::1, ::6 and ::42? Or something else?

DNS traffic to blackhole.as112.arpa (192.31.196.1 or 2001:4:112::1, so
DNAME AS112) was basically non-existant (at our node).

Checking again this morning, it is still basically true (although there
are now some very occasional sporadic queries)


P.S. I fully support using the new DNAME service (and our node is ready
for it), but I'm just wondering if it is deployed well enough to throw
.local at it.

Cheers,
Colin


-- 
Colin Petrie
Systems Engineer
RIPE NCC

From jabley at hopcount.ca  Fri Apr 22 14:44:48 2016
From: jabley at hopcount.ca (Joe Abley)
Date: Fri, 22 Apr 2016 10:44:48 -0400
Subject: [as112-ops] [gii-ops] Advice requested on a proposal to
 delegate .local to AS112
In-Reply-To: <1118a698-313a-d888-2f9b-f09cd2585ff5@ripe.net>
References: <alpine.DEB.2.20.1604211552350.3587@iskra.ottix.net>
 <etPan.57198c63.d3f4861.ced9@scallop.hopcount.ca>
 <1118a698-313a-d888-2f9b-f09cd2585ff5@ripe.net>
Message-ID: <etPan.571a38e0.667aa18e.785d@octopus.hopcount.ca>

On 22 April 2016 at 06:19:15, Colin Petrie (cpetrie=40ripe.net(mailto:cpe=
trie=40ripe.net)) wrote:
> On 22/04/16 04:28, Joe Abley wrote: =20
> >> >*) What is the criteria to declare the new AS112 worthy of having r=
eal =20
> >> >things delegated to it=3F I'm not aware of any existing delegations=
. =20
> >> >Please correct me if I'm wrong. =20
> > =20
> > The new AS112 presumably has the same number of things delegated to i=
t, =20
> > although lame delegation are possible (and no doubt detectable, if yo=
u =20
> > receive the traffic). =20
> =20
> I used the wrong word. DNAMEs, not delegations. =20

Ah, that makes more sense, then. Thanks for tolerating my pedantry :-)

It seems entirely possible that there are no significant DNAMEs installed=
 that would direct traffic to EMPTY.AS112.ARPA, because the word has simp=
ly not gone out about it.

One way to test the performance of the infrastructure in advance attracti=
ng any significant load to it might be to take a single R=46C1918 reverse=
 zone and replace the current delegation with a redirection. 239.168.192.=
IN-ADDR.ARPA or something, for example.

I think the LOCAL non-TLD is a peculiar beast to think about in this situ=
ation along a number of axes:

- there are privacy implications; if QNAMEs ending in LOCAL are going to =
leak, perhaps it's better for them to leak towards root servers who are o=
perated by a known set of actors rather than towards AS112 operators who =
are not=3F

- does the policy and operational machinery surrounding root zone mainten=
ance support the insertion of a DNAME in the root zone=3F

Testing the infrastructure behind the zone EMPTY.AS112.ARPA seems like so=
mething any number of people could look at, including RIPE Labs if APNIC =
Labs don't beat you to it. :-)

By the way, I know at least one blackhole.as112.arpa operator who is taki=
ng traffic. =46or small values of traffic. I used to do this kind of thin=
g against =46-Root when I was at ISC installing new nodes since I knew th=
at Peter Losher liked to keep a personal archive of packets received at e=
ach new node, but to my enduring disappointment I don't think he ever not=
iced.

=5Boctopus:=7E=5D% dig =40blackhole.as112.arpa hi.colin.joe.here. AAAA +n=
sid =20

; <<>> DiG 9.8.3-P1 <<>> =40blackhole.as112.arpa hi.colin.joe.here. AAAA =
+nsid
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERV=46AIL, id: 65217
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available


;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; NSID: 61 73 31 31 32 2e 68 69 76 61 6e 65 2e 6e 65 74 (a) (s) (1) (1) (=
2) (.) (h) (i) (v) (a) (n) (e) (.) (n) (e) (t)
;; QUESTION SECTION:
;hi.colin.joe.here. IN AAAA

;; Query time: 96 msec
;; SERVER: 2001:4:112::1=2353(2001:4:112::1)
;; WHEN: =46ri Apr 22 10:39:42 2016
;; MSG SIZE rcvd: 66

=5Boctopus:=7E=5D% =20


Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 101 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <https://lists.dns-oarc.net/mailman/private/as112-ops/attachments/20160422/6ad61809/attachment.sig>

From bortzmeyer at nic.fr  Sun Apr 24 08:42:44 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Sun, 24 Apr 2016 10:42:44 +0200
Subject: [as112-ops] [gii-ops] Advice requested on a proposal to
 delegate .local to AS112
In-Reply-To: <57192DE2.2000908@ripe.net>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
 <57192DE2.2000908@ripe.net>
Message-ID: <20160424084244.GA10790@sources.org>

On Thu, Apr 21, 2016 at 09:45:38PM +0200,
 Colin Petrie <cpetrie at ripe.net> wrote 
 a message of 30 lines which said:

> *) How well deployed is RFC7535 (and the corresponding implementation
> guidance in RFC7534)?

Querying RIPE Atlas probes on the SOA of empty.as112.arpa, it seems it
exists at least five nodes: ICANN, RIPE, Hivane, Ottix and a
mysterious one which does not populate the SOA properly.

[empty.as112.arpa. . 0 28800 7200 604800 86400] 
[blackhole.as112.arpa. noc.dns.icann.org. 1 604800 60 604800 604800] 
[as112.ottix.net. dns.ottix.net. 1 604800 60 604800 604800]
[as112.hivane.net. info.hivane.net. 1 604800 60 604800 604800]
[blackhole.as112.arpa. dns.ripe.net. 1 604800 60 604800 604800] 

> *) How do we measure its deployment? Atlas probes, open resolver
> *scans, etc.

I used Atlas probes.

> *) What is the criteria to declare the new AS112 worthy of having real
> things delegated to it?

You're thinking of the capacity necessary to handle the many requests
for jack-pc.local?

> I'm not aware of any existing delegations.

Me neither but we have to start somewhere. Do note that, because of
the structure of the new AS112, people can delegate to it without any
permission and you have no way to know (you'll see the increase of
traffic but not the suffix delegated, unless the prefix is revealing,
which is the case for .onion).

For testing, I delegated sink.bortzmeyer.fr to the new AS112.

% dig A foobar.sink.bortzmeyer.fr

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> A foobar.sink.bortzmeyer.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51518
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;foobar.sink.bortzmeyer.fr. IN A

;; ANSWER SECTION:
sink.bortzmeyer.fr.	86373 IN DNAME empty.as112.arpa.
sink.bortzmeyer.fr.	86373 IN RRSIG DNAME 8 3 86400 (
				20160501133113 20160412055833 38319 bortzmeyer.fr.
				eZXo1gDK4V1ZgHT9GxYvzjGFXgD794b/XY+OowBx+tqG
				4+tDEzQOJkANhJPGcF41Y2p7urtWLpzhhxjDcml4I5oq
				GYtRBVbtQXukpbvHPHRUXQU6BcIk6SQUEcbZgU+HOPeq
				94pU8TH6NpV61SoOMWyRqGvyC0fuqkuz1SHFwg8= )
foobar.sink.bortzmeyer.fr. 1800	IN CNAME foobar.empty.as112.arpa.

;; AUTHORITY SECTION:
empty.as112.arpa.	1800 IN	SOA as112.hivane.net. info.hivane.net. (
				1          ; serial
				604800     ; refresh (1 week)
				60         ; retry (1 minute)
				604800     ; expire (1 week)
				604800     ; minimum (1 week)
				)

;; Query time: 401 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sun Apr 24 10:35:25 CEST 2016
;; MSG SIZE  rcvd: 351

From bortzmeyer at nic.fr  Thu Apr 28 07:25:50 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Thu, 28 Apr 2016 09:25:50 +0200
Subject: [as112-ops] Advice requested on a proposal to delegate .local
	to AS112
In-Reply-To: <20160421185006.GA5455@laperouse.bortzmeyer.org>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
Message-ID: <20160428072550.GB31560@nic.fr>

On Thu, Apr 21, 2016 at 08:50:06PM +0200,
 Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote 
 a message of 11 lines which said:

> In the Internet-Draft "Using DNAME in the root for the delegation of
> special-use TLDs"
> <https://tools.ietf.org/html/draft-bortzmeyer-dname-root>, there is
> a proposal to delegate heavy-use non-existing TLD like .local to the
> new AS 112. Obviously, the advice of operators of the new AS 112 is
> very important. So, please, if you approve or disapprove this idea,
> speak now.

I received one approval and one request for precision. In the next
version of the Internet-Draft, can I write:

"AS 112 operators were consulted on 21-04-2016 and expressed no
objection."

?

From shane at time-travellers.org  Thu Apr 28 07:35:33 2016
From: shane at time-travellers.org (Shane Kerr)
Date: Thu, 28 Apr 2016 09:35:33 +0200
Subject: [as112-ops] Advice requested on a proposal to delegate .local
 to AS112
In-Reply-To: <20160428072550.GB31560@nic.fr>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
 <20160428072550.GB31560@nic.fr>
Message-ID: <20160428093533.02035242@pallas.home.time-travellers.org>

Stephane,

At 2016-04-28 09:25:50 +0200
Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> On Thu, Apr 21, 2016 at 08:50:06PM +0200,
>  Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote 
>  a message of 11 lines which said:
> 
> > In the Internet-Draft "Using DNAME in the root for the delegation of
> > special-use TLDs"
> > <https://tools.ietf.org/html/draft-bortzmeyer-dname-root>, there is
> > a proposal to delegate heavy-use non-existing TLD like .local to the
> > new AS 112. Obviously, the advice of operators of the new AS 112 is
> > very important. So, please, if you approve or disapprove this idea,
> > speak now.  
> 
> I received one approval and one request for precision. In the next
> version of the Internet-Draft, can I write:
> 
> "AS 112 operators were consulted on 21-04-2016 and expressed no
> objection."

Perhaps you should be explicit and say "the AS 112 operator mailing list
was consulted on 21-04-2016 and no objections were expressed"?

"AS 112 operators" without context could be interpreted as "2 or more
AS 112 operators" or possibly "all AS 112 operators". The first leaves
me wondering "*which* AS 112 operators". The second is obviously not
true, since we can't even know who all the AS 112 operators are. :)

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/mailman/private/as112-ops/attachments/20160428/de2bc9b1/attachment.sig>

From jabley at hopcount.ca  Thu Apr 28 11:43:35 2016
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 28 Apr 2016 07:43:35 -0400
Subject: [as112-ops] Advice requested on a proposal to delegate .local
	to AS112
In-Reply-To: <20160428072550.GB31560@nic.fr>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
 <20160428072550.GB31560@nic.fr>
Message-ID: <5187221F-FB22-4EAA-B9EC-17A5A7F1816E@hopcount.ca>

Hi St?phane,

On 28 Apr 2016, at 03:25, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> I received one approval and one request for precision. In the next
> version of the Internet-Draft, can I write:
> 
> "AS 112 operators were consulted on 21-04-2016 and expressed no
> objection."

That seems accurate, as written :-)

I had not noticed your draft. Since I don't have much else going on this morning over breakfast, I read it and made a few notes that might be useful (see below).


Joe

> Network Working Group                                      S. Bortzmeyer
> Internet-Draft                                                     AFNIC
> Intended status: Standards Track                          April 21, 2016
> Expires: October 23, 2016
> 
> 
>      Using DNAME in the root for the delegation of special-use TLDs
>                      draft-bortzmeyer-dname-root-01

"Root" is a bit vague if you're not a DNS addict, and "delegation" is a bit inaccurate, since you're not actually talking about a delegation here.

How about something like "Sinking Special-Use TLD Queries on AS112 Name Servers using DNAME"?

> Abstract
> 
>    This documents asks IANA to add DNAME records in the DNS root for

"root zone"

>    TLDs which are in the Special-Use Domain Names registry, in order to
>    ensure they receive an appropriate reply (NXDOMAIN) and that the root
>    is not too bothered by them.

They won't receive an NXDOMAIN from the root servers, of course.

>    REMOVE BEFORE PUBLICATION: there is no obvious place to discuss this
>    document.  May be the IETF DNSOP (DNS Operations) group, through its
>    mailing list (the author reads it).  Or may AS112 operators mailing
>    lists?  The source of the document, as well as a list of open issues,
>    is currently kept at Github [1].

You could use this list as a venue. People here are at least evidently listening.

> [...]
> 
> 1.  Introduction and background
> 
>    The DNS root receives a lot of requests for TLDs which do not exist.

Root servers receive queries for names under TLDs which do not exist.

>    See for instance [fujiwara-root-traffic] or [icann-l-root-stats] or
>    [ssac-045].  In the spirit of [RFC7534], it would be good if they
>    could be redirected to a sink such as AS112, to save root's
>    resources.

"Root servers". Specifically, the suggestion is presumably that the amount of unwanted traffic arriving at the root servers is reduced. How confident are you that this proposal would help? Name errors from the root servers are presumably cached by well-behaved clients; DNAME responses would also be cached, and name errors from AS112.ARPA servers would be cached.

Is the benefit of caching the extra DNAME non-zero for the root servers? That is, in practice, do enough clients honour TTLs and demonstrate caching of the DNAME and the name error? Note that we're talking about clients that are sufficiently poorly-behaved to be sending these queries in the first place, so relying upon their correct implementation seems potentially to be a silly thing to do.

>    Some of these names, and specially one of the biggest offenders,
>    .local ([RFC6762]), are registered in the Special-Use Domain Names
>    registry [2] of [RFC6761].  They are obvious candidates for a
>    delegation to the sink.

See above re obvious. I think there are some questions to answer to make this argument more persuasive.

>    It is proposed to use the new AS112, the one described by [RFC7535]
>    to implement this sink.
> 
>    TODO: results of the discussion with AS112 people

Hi!

> 1.1.  Requirements Terminology
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].

Incidentally you have this document marked for the standards track; BCP might be less controversial. I don't remember procedurally whether either of these is easier than the other for an individual-stream submission. You might ask a friendly AD.


> 2.  Rules
> 
>    Every TLD ([RFC7719], section 2) which is in the Special-Use Domain
>    Names registry [3] ([RFC6761]) SHOULD be delegated by IANA through a
>    DNAME to empty.as112.arpa as described in [RFC7535] if and only if
>    the registration of this TLD say that resolvers should not or must
>    not look them up in the DNS.

It might be worth spelling out what you mean by TLD. Are you just talking about single-label domains in that registry, or might you include a future name that had empty non-terminals?

Also, if it makes sense for ONION to earn a DNAME in the root zone, might it not make sense for B.E.F.IP6.ARPA or EXAMPLE.ORG? I realise those have practical problems (the former RIR policy and the latter gTLD policy) but it's not like the root zone is without those kinds of difficulties either (see below).

It's not clear if "should" or "must" are normative since they're lower-case. I presume the intention is that they are normative.

>    It is important to notice that this document does not define a policy
>    to decide if a TLD should be "delegated" or not.  Instead, it relies
>    on the existing Special-Use Domain Names registry and its rules.
> 
>    RFC-EDITOR: remove before publication.  As of today, with these
>    rules, .local ([RFC6762]) or .onion ([RFC7686]) would be delegated
>    but not .example (its registration in [RFC6761] does not define
>    special handling for resolvers) or .home or .belkin (this last one
>    generates a huge traffic at the root but is not in the Special-Use
>    Domain Names registry).
> 
> 3.  Benefits
> 
>    The main benefit is less load on the root and a better efficiency of
>    the caches, therefore helping the entire DNS ecosystem.

See above. I think some investigation of this benefit both with reference to the standards and with reference to observed traffic is warranted.

> 4.  Possible issues
> 
>    Of course, the solution described in this document requires a good
>    support of DNAME by the resolvers.  Appendix A of [RFC7535] describes
>    an experiment which was run in 2013 and which shows that, indeed, we
>    can rely on DNAME (quoting the authors: "We conclude that there is no
>    evidence of a consistent failure on the part of deployed DNS
>    resolvers to correctly resolve a DNAME construct.").

As co-author of 7535 I approve of this message.

>    Regarding DNSSEC, do note the future DNAMEs in the root will be
>    signed, but the target, empty.as112.arpa, is not.  See George
>    Michaelson's message [4].  So, it will not be possible to validate
>    the answers.  Not a problem since these requests should never have
>    been sent to the root, anyway.

I seem to recall there is some commentary in 7535 about this. Signatures over EMPTY.AS112.ARPA have no value since they would rely upon the use of a private key that was essentially public. Any signature would be compromised and therefore useless (untrustworthy) by design.

> 5.  IANA Considerations
> 
>    IANA is requested (TODO what is the appropriate wording?) to add a
>    DNAME in the root for every TLD which fits the rules of Section 2.

I usually direct the IANA. And when I see them at meetings I buy Michelle a beer.

>    RFC-EDITOR: remove before publication.  There is currently no DNAME
>    in the root.  It is expected that the creation of the first one will
>    require a top-down, multi-stakeholder, long and complicated process
>    with a lot of meetings, reports by consultants and design teams.

I think it's anybody's guess would be or might not be difficult with regard to root zone management policy at this current point in governance history. Back in the days when variant IDN TLDs were a hot topic there was at least one investigation into the use of DNAME in the root zone commissioned, however, and I remember that report being delivered and published. Whether or not you can find it today is a separate question :-) The author was Jo?o Damas who you know, so you might ask him if Google has not heard of it.

I would observe though that the machinery currently in place to manage the contents of the root zone took years and years to implement, and to my knowledge only supports delegation (with NS sets). So presumably if there was a call to deploy DNAMEs in the root zone that was not held up indefinitely for layer-9 reasons, that machinery would not be used and the DNAMEs would be added in the same way that other irregular changes (like root servers being renumbered) that don't fit in RZM are managed.

> 6.  Security Considerations
> 
>    The requests for the TLD in the Special-Use Domain Names registry are
>    typically NOT supposed to leak to the authoritative public name
>    servers such as the ones of the root.  If they do, it means a
>    misconfiguration somewhere.  The leak is independant on whether the
>    name is delegated to AS112 or not.  See section 8 of [RFC7534] for an
>    analysis.  Some people believe there are added risks, because the
>    queries will be seen by AS112 servers which, unlike the root, are
>    managed by many "random people".

I think this document needs some discussion of the privacy implications.

This document would leave a dribble of leaked queries for special-use names on the root servers, but would (likely, see above) send the bulk of it to AS112 servers. This means that population of people who can see the query streams is increased from the set of root server operators and people that they (e.g.) share DITL data with, to potentially anybody. There's no defence against a malefactor hijacking AS112 traffic, because in a real sense that traffic is intended to be hijacked.

This seems like a problem for LOCAL and ONION, since in both cases the whole special-use specified for them involves the isolation of resolution to a separate protocol, and any unexpected leaking is bad but presumably more is worse. This proposal would cause queries to leak further, which feels a bit like more? Perhaps that's worse?


Joe



From bortzmeyer at nic.fr  Fri Apr 29 13:52:53 2016
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 29 Apr 2016 15:52:53 +0200
Subject: [as112-ops] Advice requested on a proposal to delegate .local
 to AS112
In-Reply-To: <5187221F-FB22-4EAA-B9EC-17A5A7F1816E@hopcount.ca>
References: <20160421185006.GA5455@laperouse.bortzmeyer.org>
 <20160428072550.GB31560@nic.fr>
 <5187221F-FB22-4EAA-B9EC-17A5A7F1816E@hopcount.ca>
Message-ID: <20160429135253.GA23568@nic.fr>

On Thu, Apr 28, 2016 at 07:43:35AM -0400,
 Joe Abley <jabley at hopcount.ca> wrote 
 a message of 252 lines which said:

> "Root" is a bit vague if you're not a DNS addict,

OK, I made sure that root is never used naked and that it's always
"root zone" or "root nameservers" depending on the case.

> and "delegation" is a bit inaccurate, since you're not actually
> talking about a delegation here.

RFC 7534 uses it "The extension of the AS112 service to include the
ability to have additional zones delegated for sinking or removed
using the DNAME resource record."

While searching for a better term ("redirection"?), I put it between
quotes everywhere.
   
> >    TLDs which are in the Special-Use Domain Names registry, in
> >    order to ensure they receive an appropriate reply (NXDOMAIN)
> >    and that the root is not too bothered by them.
> 
> They won't receive an NXDOMAIN from the root servers, of course.

They do but the important word is "and"

> Specifically, the suggestion is presumably that the amount of
> unwanted traffic arriving at the root servers is reduced. How
> confident are you that this proposal would help? Name errors from
> the root servers are presumably cached by well-behaved clients;
> DNAME responses would also be cached, and name errors from
> AS112.ARPA servers would be cached.
> 
> Is the benefit of caching the extra DNAME non-zero for the root
> servers? That is, in practice, do enough clients honour TTLs and
> demonstrate caching of the DNAME and the name error? Note that we're
> talking about clients that are sufficiently poorly-behaved to be
> sending these queries in the first place, so relying upon their
> correct implementation seems potentially to be a silly thing to do.

Caching does not solve everything because a request to the resolver for
le-pc-de-jean.local followed by one for joe-s-pc.local would still
make two requests. See draft-dnsop-nxdomain-cut for details and
discussion.

Regarding the "badly behaved" argument, I think there are two ways to
be badly behaved. One is a configuration error, the machines query a
resolver which is not authoritative for .local and therefore leak
data. Such setup is bad (it sends .local queries to the root
nameservers) but it normal, from a DNS protocol point of view. Such a
resolver would obey caching, DNAME, etc.

The second way is really broken software, sending queries
everywhere. In that case, and in that case only, you are right, they
would not use the new sink.

Any idea of a test setup to prove that there would be a win? Because
we can suspect that many real clients would not behave properly, a lab
with BIND, NSD and Unbound would not be enough. IMHO, the only real
way to be sure would be to add a DNAME during 24 hours in the real
root (may be during a DITL).

> Incidentally you have this document marked for the standards track;
> BCP might be less controversial.

This document requests IANA to do something in a critical resource. I
don't think it will work without at least a document on the standards
track.

> >    Every TLD ([RFC7719], section 2) which is in the Special-Use
> >    Domain Names registry [3] ([RFC6761]) SHOULD be delegated by
> >    IANA through a DNAME to empty.as112.arpa as described in
> >    [RFC7535] if and only if the registration of this TLD say that
> >    resolvers should not or must not look them up in the DNS.
> 
> It might be worth spelling out what you mean by TLD.

RFC 7719, section 2 :-)

> Are you just talking about single-label domains in that registry, or
> might you include a future name that had empty non-terminals?

Well, other non-TLD names make less problems. 
 
> Also, if it makes sense for ONION to earn a DNAME in the root zone,
> might it not make sense for B.E.F.IP6.ARPA or EXAMPLE.ORG?

example.org does not fit the rules (no special handling in the DNS),
anyway. That's not because it is made of two labels. 

> It's not clear if "should" or "must" are normative since they're
> lower-case. I presume the intention is that they are normative.

It's complicated because it's a reference to the RFCs actually
"reserving" these TLD. The RFCs use capitals, so I switched to capitals.

> >    Regarding DNSSEC, do note the future DNAMEs in the root will be
> >    signed, but the target, empty.as112.arpa, is not.
> 
> I seem to recall there is some commentary in 7535 about this.

I didn't find it.

> Signatures over EMPTY.AS112.ARPA have no value since they would rely
> upon the use of a private key that was essentially public. Any
> signature would be compromised and therefore useless (untrustworthy)
> by design.

I agree.

> I usually direct the IANA. And when I see them at meetings I buy
> Michelle a beer.

Not Amanda?

> at least one investigation into the use of DNAME in the root zone
> commissioned, however, and I remember that report being delivered
> and published. Whether or not you can find it today is a separate
> question :-) The author was Jo?o Damas

Added to the draft (as well as SAC-009 and a few others).

> that machinery would not be used and the DNAMEs would be added in
> the same way that other irregular changes (like root servers being
> renumbered) that don't fit in RZM are managed.

Not a real problem, the Special-Use domain registry is quite static.

draft-bortzmeyer-dname-root-02 now published, thanks.

