[as112-ops] [gii-ops] Advice requested on a proposal to delegate .local to AS112

Joe Abley jabley at hopcount.ca
Fri Apr 22 14:44:48 UTC 2016


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>


More information about the as112-ops mailing list