[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Christian Huitema" <huitema@exchange.microsoft.com>
cc: "Randy Bush" <randy@psg.com>, "Bill Manning" <bmanning@isi.edu>, perry@wasabisystems.com, seamus@bit-net.com, users@ipv6.org, dnsop@cafax.se, ngtrans@sunroof.eng.sun.com
From: itojun@iijlab.net
Date: Fri, 19 Jan 2001 03:01:04 +0900
In-reply-to: huitema's message of Thu, 18 Jan 2001 09:32:27 PST. <CC2E64D4B3BAB646A87B5A3AE97090420EFADA00@speak.dogfood>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Re: IPv6 dns


>During a trial, this can be done by operating on a trial subtree for
>names. Something like <example>.ipv6dns.org. During the transition,
>however, we want to progressively publish A6 records for the name
>servers of regular domains. Obviously, any domain manager can do this on
>their own initiative: for example, Microsoft could add an NS record
>pointing to a v6 capable server under "microsoft.com". However, this
>impacts the general infrastructure, since the servers for microsoft.com
>and their address must be provided by the ".com" server.  Randy has a
>first point there: we have to understand the potential impact of serving
>A6 records to vanilla .com users; we may have to set up a conservative
>rule, such as only serving these records if the query for the .com user
>was received over IPv6. Or maybe we need not be that conservative; but
>we should try. And, maybe, just maybe, we should not try first with
>".com." 

	I think:
	- it should be okay to deploy AAAA records to certain degree
	- we need to be very conservative about deplying A6 records,
	  as A6 presents highly different behavior than A/AAAA records.
	  # of queries would increase, # of additoinal records would
	  go skyrocket.

	about AAAA:

	Situation may be different from ".com.", but there are registries that
	accept NS record registration with IPv6 address (NS record that
	points to AAAA record).  For example, JPNIC do this:
	http://www.nic.ad.jp/en/topics/archive/20000301-01.html
	and if you would like to see an example, try looking up NS for
	wide.ad.jp.
	% dig wide.ad.jp. ns
	% whois -h whois.nic.ad.jp wide.ad.jp/e
	% whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e

	also, there are many MX records that point to AAAA record.  for
	example, try jp.freebsd.org. and wide.ad.jp.
	% dig jp.freebsd.org. mx
	% dig wide.ad.jp. mx

	both of them looks to be working fine.  we have conducted detailed
	test against MTAs, to see if they works okay with MX record that
	points to AAAA records.  I remember that it worked just fine.
	motonori@wide.ad.jp should have more detail.

	about A6:

	If we deploy A6 records, situation with additional records will get
	much, much, much worse than AAAA additional records.
	Here's an example (thanks jinmei!).

% dig @0.0.0.0 paradise.v6.kame.net. a6

; <<>> DiG 9.0.1 <<>> @0.0.0.0 paradise.v6.kame.net. a6
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54685
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 8

;; QUESTION SECTION:
;paradise.v6.kame.net.          IN      A6

;; ANSWER SECTION:
paradise.v6.kame.net.   158     IN      A6      64 ::2e0:18ff:fe98:f19d sharedsegment.a6.kame.net.
paradise.v6.kame.net.   158     IN      A6      64 ::2e0:18ff:fe98:f19d karigome-bb.v6.wide.ad.jp.

;; AUTHORITY SECTION:
kame.net.               1748    IN      NS      coconut.itojun.org.
kame.net.               1748    IN      NS      tiger.hiroo.oshokuji.org.
kame.net.               1748    IN      NS      orange.kame.net.

;; ADDITIONAL SECTION:
sharedsegment.a6.kame.net. 158  IN      A6      48 0:0:0:2000:: karigome.v6.wide.ad.jp.
karigome.v6.wide.ad.jp. 3600    IN      A6      32 0:0:4819:: wide-6bone.v6.wide.ad.jp.
wide-6bone.v6.wide.ad.jp. 3600  IN      A6      0 3ffe:501::
karigome-bb.v6.wide.ad.jp. 3600 IN      A6      48 0:0:0:4819:: wide-stla.v6.wide.ad.jp.
wide-stla.v6.wide.ad.jp. 3600   IN      A6      0 2001:200::
coconut.itojun.org.     8       IN      A       210.160.95.97
tiger.hiroo.oshokuji.org. 8     IN      A       210.145.33.242
orange.kame.net.        897     IN      A       203.178.141.194

;; Query time: 83 msec

>The same indeed apply for the root itself. If we say that ".com" will
>only provide A6 records in the additional section if the query was
>received over IPv6, then we must find a way to publish the IPv6 address
>of the suitable .com server, and that must be done by the root. Indeed,
>that must be done by the root for every TLD who wants to enable IPv6.
>And there are good reasons to be very conservative with the handling of
>the root service.

	I'm curious about:
	- packet size requirement when we include A6/AAAA records into "."
	  queries.
	- deployment status of EDNS0 to IPv6 transport-capable resolvers

>Randy also asked, what happens if an IPv6 only DNS resolver tries to get
>information about an IPv4 domain. The obvious answer is to use a dual
>mode server as proxy. However, this requires some configuration, which
>Ngtrans should automatize. Now, that would would be a work item for this
>group...

	I don't think such a DNS server should be widely deployed.  such a
	A-to-A6/AAAA rewriting nameservers should be located in leaf sites,
	for use within the leaf site only, and every efforts should be
	made to avoid leakage of rewritten records.

	for actual implementation, see totd from Feico Dillema.
	http://www.vermicelli.pasta.cs.uit.no/ipv6/software.html

itojun

Home | Date list | Subject list