On Oct 25, 2013, at 3:45 PM, Randy Bush wrote:

>> xn--ngbc5azd.                172800  IN      NS      a.nic.xn--ngbc5azd.
>> xn--ngbc5azd.                172800  IN      NS      b.nic.xn--ngbc5azd.
>> xn--ngbc5azd.                172800  IN      NS      c.nic.xn--ngbc5azd.
>> xn--ngbc5azd.                172800  IN      NS      d.nic.xn--ngbc5azd.
>> a.nic.xn--ngbc5azd.  172800  IN      A       37.209.192.3
>> a.nic.xn--ngbc5azd.  172800  IN      AAAA    2001:dcd:1:0:0:0:0:3
>> b.nic.xn--ngbc5azd.  172800  IN      A       37.209.194.3
>> b.nic.xn--ngbc5azd.  172800  IN      AAAA    2001:dcd:2:0:0:0:0:3
>> c.nic.xn--ngbc5azd.  172800  IN      A       37.209.196.3
>> c.nic.xn--ngbc5azd.  172800  IN      AAAA    2001:dcd:3:0:0:0:0:3
>> d.nic.xn--ngbc5azd.  172800  IN      A       37.209.198.3
>> d.nic.xn--ngbc5azd.  172800  IN      AAAA    2001:dcd:4:0:0:0:0:3
>> 
>> This works, of course, but it feels a bit fragile for me. Is there a
>> history of this being unsafe? Of being more safe than NSs whose names
>> are in other TLDs?
> 
> what do you think is fragile?  the in-baliwick glue?  why?
> 
> the ip address clumping would worry me if i thought they were not
> anycast.
> 
> randy

Someone did a comparison between all the ccTLD's a few years back (was it 
CENTR? or RIPE? I cant find it...) where they checked stuff like this. I think 
I remember 100% in-bailiwick glue was considered best as this gives most 
control to the TLD itself and has the least risk of hijacking due to inzone or 
out of zone dependancies.

I actually agree with this assessment, at least as long as (in the example 
above) the zone "nic.xn--ngb5azd" is *very* well guarded (locked utterly) and 
preferrably also never delegated. Which it might actually be, then it's 
suddenly much riskier as you must have full control of the delegated zone also 
(which I kind of consider an inzone dependancy)...

(Compare: In .SE the zone "NS.SE" that contains all names of all NS-records for 
.SE is in-bailiwick and *not* a delegated zone).

BigMac:~ einar.lonn$ dig se ns +short
a.ns.se.
b.ns.se.
c.ns.se.
d.ns.se.
e.ns.se.
f.ns.se.
g.ns.se.
i.ns.se.
j.ns.se.

BigMac:~ einar.lonn$ dig ns.se ns @a.ns.se       

; <<>> DiG 9.8.5-P1 <<>> ns.se @a.ns.se
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6494
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns.se.                         IN      A

;; AUTHORITY SECTION:
se.                     7200    IN      SOA     catcher-in-the-rye.nic.se. 
registry-default.nic.se. 2013102506 1800 1800 864000 7200

;; Query time: 45 msec
;; SERVER: 192.36.144.107#53(192.36.144.107)
;; WHEN: Fri Oct 25 16:54:07 CEST 2013
;; MSG SIZE  rcvd: 99

Wish I could find that survey with the comparison, anyone remember it? It was a 
good one and gave out gold stars and such for nice DNS setups, which was kind 
of fun… ;)


        /Regards, Einar

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to