[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt
- To: Paul Vixie <paul@vix.com>, v6ops@ops.ietf.org
- Subject: Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt
- From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
- Date: Sat, 26 Oct 2002 02:11:15 +0900
- Delivery-date: Fri, 25 Oct 2002 10:12:14 -0700
- Envelope-to: v6ops-data@psg.com
>>> >i suggest adding a reference to http://www.isc.org/tn/isc-tn-2002-1.txt,
>>> >which addresses some of the dns-related issues in migrating away from 6bone.
>>> two comments -
>>> 1. DNAME is not widely implemented in resolvers in the wild. therefore
>>> not many will be able to resolve "blah.int" with this scheme.
>>the dname logic executes in the authority servers, by synthesizing cnames.
>>so as long as the master and all slaves understand dname, this proposal works.
>
> then
> - how do you sign a zone with DNAME? synthesize = you can't sign.
> - why DNAME resolution has to be kept in BIND8 resolver?
> (i have sent a diff to remove DNAME processing in BIND8 resolver
> distributed in BIND9 package, and i got "don't remove DNAME" comment)
and
- RFC2672 doesn't say that DNAME is a pseudo RR type (which does not
appear on wire), so i assume it is a real RR tyep (which appears
on the wire). this is opposite from your statement above.
itojun