[dns-operations] TLD zones with lame servers

Tue Jun 11 04:36:26 UTC 2019

> On 11 Jun 2019, at 2:17 pm, Paul Vixie <paul at redbarn.org> wrote:
> 
> On Tuesday, 11 June 2019 03:50:18 UTC Mark Andrews wrote:
>>> On 11 Jun 2019, at 12:49 pm, Doug Barton <dougb at dougbarton.email> wrote:
>>> 
>>> ... there is no mechanism currently for ICANN to remove a name server
>>> from a delegation without permission from the ccTLD Manager. Absent a
>>> specific policy or mechanism that comes from the ICANN process, they
>>> would be wrong to do so.
>> Which is a gross omission.  Operators of servers need to have to the ability
>> to remove themselves from a delegation.
> 
> i once owned a domain (2LD.1LD) name one of whose subdomains (3LD.2LD.1LD) was 
> used as a delegated name server by several TLD's. i asked, for several years, 
> to have the name changed to 3LD.2LD'.1LD', since there was another name that 
> had the same IP address and performed the same service. no dice -- there was 
> no process for it.
> 
> so i sold the domain, and informed my friends within ICANN of the date-certain 
> when the parent domain would go outside my control. then, they found a way.
> 
> my friends within ICANN are heroes. i believe that they, and because of them 
> the organization, does _all it can_ to get to good outcomes. but, we're merely 
> human, and so, shackled by tradition, superstition, and necessary respect for 
> the rules of both law and contracts. thus, all the "muddling through" we do.
> 
>>> I have as much sympathy for the technical correctness argument as anyone
>>> else, but what we would consider to be a clear bright line is a slippery
>>> slope to others, with a pool of hangry alligators at the bottom.
> 
> i suggest that a demand from the administrator of 2LD.1LD to remove a name 
> like 3LD.2LD.1LD from some TLD delegation, must be honoured by ICANN, with 
> notice but no other regard for the wishes of the TLD operator, and that this 
> rule change should be considered noncontroversial by all parties. if the TLD 
> operator makes no similar edit to their apex NS RRset, that's another problem, 
> subject to other solutions, and unrelated to this process question.
> 
> note, marka's original topic was different, so, this is a threadjacking.

Well there were several issues. For

cm. cm.cctld.authdns.ripe.net: no address records found (NXDOMAIN)

the NS record doesn’t exist in the CM zone.  It only exists in the root zone
so if IANA honoured a request from RIPE to remove their server this particular
problem would be addressed.  Unfortunately I don’t think RIPE NCC want to sell
ripe.net to resolve the issue as you were forced to do.

I also don’t consider this a thread hijacking.  Having IANA remove delegating
NS records at the requested of the delegated server operator should be part
of the solution space.

[beetle:~/git/bind9] marka% dig ns cm @a.root-servers.net

; <<>> DiG 9.15.0 <<>> ns cm @a.root-servers.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37598
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;cm.				IN	NS

;; AUTHORITY SECTION:
cm.			172800	IN	NS	cm.cctld.authdns.ripe.net.
cm.			172800	IN	NS	ns.itu.ch.
cm.			172800	IN	NS	kim.camnet.cm.
cm.			172800	IN	NS	lom.camnet.cm.
cm.			172800	IN	NS	auth02.ns.uu.net.
cm.			172800	IN	NS	sanaga.camnet.cm.

;; ADDITIONAL SECTION:
cm.cctld.authdns.ripe.net. 172800 IN	A	193.0.9.68
ns.itu.ch.		172800	IN	A	156.106.192.121
kim.camnet.cm.		172800	IN	A	195.24.192.35
lom.camnet.cm.		172800	IN	A	195.24.192.34
auth02.ns.uu.net.	172800	IN	A	198.6.1.82
sanaga.camnet.cm.	172800	IN	A	195.24.192.17
cm.cctld.authdns.ripe.net. 172800 IN	AAAA	2001:67c:e0::68
ns.itu.ch.		172800	IN	AAAA	2a00:7580:60:2141::10

;; Query time: 178 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Jun 11 14:22:42 AEST 2019
;; MSG SIZE  rcvd: 336

[beetle:~/git/bind9] marka% dig ns cm @lom.camnet.cm

; <<>> DiG 9.15.0] <<>> ns cm @lom.camnet.cm
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41039
;; flags: qr aa rd; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 15
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cm.				IN	NS

;; ANSWER SECTION:
cm.			86400	IN	NS	ns2.nic.cm.
cm.			86400	IN	NS	mbam.camnet.cm.
cm.			86400	IN	NS	ns-cm.nic.fr.
cm.			86400	IN	NS	ns-cm.afrinic.net.
cm.			86400	IN	NS	auth02.ns.uu.net.
cm.			86400	IN	NS	benoue.camnet.cm.
cm.			86400	IN	NS	phloem.uoregon.edu.
cm.			86400	IN	NS	ns.itu.ch.
cm.			86400	IN	NS	kim.camnet.cm.
cm.			86400	IN	NS	lom.camnet.cm.
cm.			86400	IN	NS	ns1.nic.cm.

;; ADDITIONAL SECTION:
ns.itu.ch.		2243	IN	A	156.106.192.121
ns.itu.ch.		2244	IN	AAAA	2a00:7580:60:2141::10
kim.camnet.cm.		86400	IN	A	195.24.192.35
lom.camnet.cm.		86400	IN	A	195.24.192.34
ns2.nic.cm.		2645	IN	A	195.24.205.61
mbam.camnet.cm.		86400	IN	A	195.24.192.33
ns-cm.nic.fr.		89044	IN	A	194.0.9.1
ns-cm.nic.fr.		89046	IN	AAAA	2001:678:c::1
ns-cm.afrinic.net.	2243	IN	A	196.216.168.67
ns-cm.afrinic.net.	2243	IN	AAAA	2001:43f8:120::67
auth02.ns.uu.net.	2243	IN	A	198.6.1.82
benoue.camnet.cm.	86400	IN	A	195.24.208.2
phloem.uoregon.edu.	2644	IN	A	128.223.32.35
phloem.uoregon.edu.	2646	IN	AAAA	2001:468:d01:20::80df:2023

;; Query time: 515 msec
;; SERVER: 195.24.192.34#53(195.24.192.34)
;; WHEN: Tue Jun 11 14:23:07 AEST 2019
;; MSG SIZE  rcvd: 565

[beetle:~/git/bind9] marka% 

> -- 
> Paul
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org