Re: (ngtrans) Re: IPv6 dns

[Jim Bound <seamus@bit-net.com>]

Itojun,

I agree with you we should be fine deploying AAA records.  I also agree
we need to be skeptical about A6 and if they continue to exist we need to 
for sure do the type of experiments Randy suggested.

/jim

On Fri, 19 Jan 2001 itojun@iijlab.net wrote:

> 
> >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
>