[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt
- To: v6ops@ops.ietf.org
- Subject: Re: I-D ACTION:draft-savola-v6ops-6bone-mess-00.txt
- From: Paul Vixie <paul@vix.com>
- Date: Fri, 25 Oct 2002 19:47:53 +0000
- Delivery-date: Fri, 25 Oct 2002 12:49:00 -0700
- Envelope-to: v6ops-data@psg.com
this isn't specifically ipv6 related, but it has to do with DNAME, which
is referred to in ISC-TN-2002-1 that was URL'd here earlier, so:
(my thanks to nominum for help providing these answers)
> - how do you sign a zone with DNAME? synthesize = you can't sign.
The synthesized CNAME won't be signed, but the DNAME will. This just
means that anything capable of DNSSEC validation must look at the DNAME,
not the CNAME. That's exactly what BIND 9's internal resolver does.
> - 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)
it should have been removed when we tore dnssec support out of bind8. my
apologies for rejecting your patch earlier. please resend :-).
> - 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.
It is a real RR type. Any server that doesn't understand DNAMEs should
treat it no differently than any other unknown RR types, and things will
still work (because of the synthesized CNAMEs).