IETF Logo Mail Archive

Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt

Shane Kerr <shane@time-travellers.org> Mon, 27 November 2017 12:54 UTC

Return-Path: <shane@time-travellers.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4747E128616 for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 04:54:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.401
X-Spam-Level:
X-Spam-Status: No, score=-0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn6HiVbu_0ic for <dnsop@ietfa.amsl.com>; Mon, 27 Nov 2017 04:54:30 -0800 (PST)
Received: from time-travellers.nl.eu.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D42F12711E for <dnsop@ietf.org>; Mon, 27 Nov 2017 04:54:30 -0800 (PST)
Received: from [65.19.167.132] (helo=[127.0.0.1]) by time-travellers.nl.eu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1eJIy4-0003x3-BY; Mon, 27 Nov 2017 12:57:01 +0000
From: Shane Kerr <shane@time-travellers.org>
To: Tony Finch <dot@dotat.at>
Cc: dnsop@ietf.org
References: <151155545267.9162.17152586924934799206.idtracker@ietfa.amsl.com> <B0A6AF83-099A-4D4D-83EB-BA4B45D00353@consulintel.es> <2E863078-8E32-4657-B1F4-0417A0C95A05@consulintel.es> <18C3DFC8-45B9-4C41-8151-ACA840F00518@gmail.com> <9B47C38D-B446-466F-BE88-DD09E40814B3@hopcount.ca> <alpine.DEB.2.11.1711271220410.4416@grey.csi.cam.ac.uk>
Message-ID: <287a9276-9e7a-5031-cded-55f4514d9bf6@time-travellers.org>
Date: Mon, 27 Nov 2017 12:54:00 +0000
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1711271220410.4416@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KJChmIS9U-AQntl1yYiaPNibUt0>
Subject: Re: [DNSOP] [v6ops] New Version Notification for draft-palet-sunset4-ipv6-ready-dns-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2017 12:54:32 -0000

Tony,

Tony Finch:
> Joe Abley <jabley@hopcount.ca> wrote:
>>
>> There are potentially 249 TLDs that are not operated under any such
>> contract with ICANN, although I agree that the majority of ccTLDs have
>> at least one nameserver that is v6-capable (maybe all, but I haven't
>> checked and I wouldn't want to assume).
> 
> Quick root zone stats:
> 
> zones 1542
> servers 4216
> 
> Most servers are dual-stacked; 539 are v4-only, and 2 are v6-only
> (j.zdnscloud.com and i.zdnscloud.com).
> 
> The 31 TLDs with no v6 nameservers:
> 
> ai.
[ snippity ]
> zw.

Your list is missing bf., which does not appear to have any IPv6 name
servers right now.

It also counts quite a few more than my checks:

gf.
mq.
mh.
mv.
ni.
xn--lgbbat1ad8j.
ye.
zw.

I'm not sure what your methodology is exactly, but I put mine on GitHub:

https://github.com/shane-kerr/tldIPv6

My guess is that you just looked at the root zone itself, since I see
that bf. has IPv6 glue:

;; AUTHORITY SECTION:
bf.			172800	IN	NS	nahouri.onatel.bf.
bf.			172800	IN	NS	ns-bf.afrinic.net.
bf.			172800	IN	NS	censvrns0001.ird.fr.

;; ADDITIONAL SECTION:
ns-bf.afrinic.net.	172800	IN	AAAA	2001:43f8:120::34
nahouri.onatel.bf.	172800	IN	A	206.82.130.196
ns-bf.afrinic.net.	172800	IN	A	196.216.168.34
censvrns0001.ird.fr.	172800	IN	A	91.203.32.147

Whereas zw. does not:

zw.			172800	IN	NS	ns2.telone.co.zw.
zw.			172800	IN	NS	ns3.telone.co.zw.
zw.			172800	IN	NS	ns2.gip.net.
zw.			172800	IN	NS	ns1.telone.co.zw.

;; ADDITIONAL SECTION:
ns1.telone.co.zw.	172800	IN	A	194.133.122.47
ns2.gip.net.		172800	IN	A	204.59.1.222
ns2.telone.co.zw.	172800	IN	A	194.133.122.42
ns3.telone.co.zw.	172800	IN	A	194.133.122.34

Probably I should update my code to *ALSO* check whether or not a zone
has some usable IPv6 path either through glue or a name server under a
TLD that supports IPv6. I suppose it can verify glue at the same time.
(I'm not sure what happens in a resolver to a zone like bf., when below
the zone cut IPv6 is *not* supported but above the zone cut it *is*, due
to mismatched glue.)

Cheers,

--
Shane

v2.23.0 | Report a Bug | By Email