On Mon, May 11, 2015 at 12:10 PM, 神明達哉 <jin...@wide.ad.jp> wrote:
> At Sat, 9 May 2015 18:50:28 +0000, > Evan Hunt <e...@isc.org> wrote: > > > Actually, weirdly enough, after I implemented NTA's in BIND, one of the > > very first applications somebody came up with for them was to temporarily > > disable DNSSEC validation by setting an NTA for ".". This was seen as > > better than "rndc validation off" because he didn't have to send "rndc > > validation on" afterward; it would just quiety switch itself back on > > after a minute. It's... actually a pretty clever hack, and I don't > > really want to disable it. > > > > May I suggest: "An NTA placed at a node where there is a configured > > positive trust anchor takes precendence over that trust anchor, > effectively > > disabling it. Implementations MAY issue a warning when this occurs." > > Does this mean: > > A: All implementations that conform to this document should prefer the > NTA over the positive anchor in such a case, or > B: This is implementation-dependent, but if an implementation allows > the coexistence of positive and negative anchors, it should prefer > the NTA, or > C: something else? > > I don't have a strong opinion between A and B, but I'd like this > document to be clear on this. And, if it means A, I'd use an RFC2119 > keyword (it's probably a SHOULD). > > -- > JINMEI, Tatuya > I think "A" is the right answer. Otherwise you run into situations where you need an NTA, but it won't work. I am not even sure there is a good reason for a warning. The zone is supposed to be signed, but the signing is broken, and the resolver operator has determined that it is due to a mistake, and decided to apply an NTA, same as any other situation. Whether the signing comes from the root or a positive anchor seems irrelevant to me. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
