Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 4 May 2015 15:26:45 +0100

Hi

I have reviewed this document, and support its publication as is.

Olafur

On Mon, Apr 27, 2015 at 11:58 PM, Tim Wicinski <[email-masked]> wrote:

> Greetings,
>
> This starts a Working Group Last Call for Adoption for
> draft-ietf-dnsop-negative-trust-anchors
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
>
> https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04
>
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons
>
> This starts a two week Working Group Last Call process, and ends on May
> 11th, 2015.
>
> thanks
> tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: 神明達哉 <[email-masked]>
Date: Mon, 4 May 2015 11:25:38 -0700

At Mon, 27 Apr 2015 18:58:10 -0400,

> draft-ietf-dnsop-negative-trust-anchors

(I guess this is "for Publication", not "for Adoption").

Also, have we decided to publish it as an Informational document?  I'm
not opposed to it, but this document contains some normative text and
affects inseparability in some sense, so a standard truck seems to be
a more appropriate choice for me.

> feels the document is *not* ready for publication, please speak out with

I do not think it's ready for publication yet.

I'd like to see a discussion on whether it really makes sense that an
NTA for a domain name even disables a positive trust anchor below the
name.  I made more specific comment on this in a separate message:
http://www.ietf.org/mail-archive/web/dnsop/current/msg14170.html
(with some other comments on the 04 version of the draft).

I also think Appendix B needs more editorial cleanups.  Those
editorial matters may not be a showstopper by themselves, but I guess
it's better to fix them before sending it to the IESG.

A couple of other comments on version 4:

- Section 4:
   It is therefore
   recommended that NTA implementors should periodically attempt to
   validate the domain in question, for the period of time that the

  I guess this 'recommended' may be better RFC2119 capitalized, i.e.,
  "RECOMMENDED".  Not a strong opinion, but it seems to me to be more
  aligned with general tone and other usage of RFC2119 keywords of
  this section.

- Section 4: likewise, maybe s/should/SHOULD/
   When removing the NTA, the implementation should remove all cached
   entries below the NTA node.

Editorial and minor comments:

- Section 3: there's an awkward blank line (and spaces) before the
  reference:
   names for a Negative Trust Anchor.  For example, Unbound calls their
   configuration "domain-insecure."

   [Unbound-Configuration]

- Section 7.1: s/has have/has/
   Thus, there may be a gap between when a domain has have been re-

- Appendix B: s/servers/server's/ (?)
   domain is consistency and history.  It therefore is good if you have
   the ability to look at the servers DNS traffic over a long period of

- Appendix B: s/them install/install them/
   most of these tools are open source so you can them install locally
   if you want.

- Appendix B: this sentence doesn't parse well to me...

   Using the tools over the Internet has the advantage though that as
   these are not located in the same part of the network you already
   will have more than local view by using different tools.

- Appendix B: s/server.s/servers./
   consistently around the world and from all authoritative server.s Use

- Appendix B: s/an guarantee/a guarantee/
   attack, although that is not an guarantee.  Also if the output from

- Appendix B: it's now a dnsop wg document
   EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to
   the domain.

- Appendix B: this sentence doesn't parse well to me...

   Again if the data is the same this
   is an indication that the error is operator caused not an guarantee.

- Appendix B: s/parents/parent's/ (or "parent zone's ?)
   o  DNSKEYs in child zone don't match parents zone DS record.  There

- Appendix B: these two sentences seem too informal grammatically, if
  not broken:
      Has the existed before and was used?
      Was there a change in the DNSKEY RRSet recently (indicating a key
      rollover) and of course has the actual data in the zone changes.

- Appendix B:
   o  Data in DS or DNSKEY doesn't match the other.  This is more common
      in initial setup when there was a copy and paste error.  Again
      checking history on data is the best you can do there.  It's not
      possible to give a checklist just to run through to decide if a
      domain is broken because of an attack or an operator error.

  Is the "It's not possible..." sentence supposed to belong to the
  bullet?  This sentence seems to talk about something general, and
  seem to make more sense if it's part of the sentence that follows:

   All of the above is just a starting point for consideration when
   having to decide to deploy or not deploy a trust anchor.

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 May 2015 12:24:13 -0400

[ Top post]
Only replying to the biggest issue here, will reply to the rest later today.

> (with some other comments on the 04 version of the draft).

So, I got a little confused by this comment (because that isn't what
I'd meant to say), and so went back to Jinmei's comments on -04... and
realized that I'd misunderstood one of them (I'd missed the "positive"
in the question).

The way that our resolver works is that the closest TA would win, and
so a positive TA under a negative trust anchor *would* be used. To me
this seems to be the obviously right thing to do, and so, unless
anyone objects, I'll add text to the document stating that.

So, in summary, a configured *positive* trust anchor for
good.subdomain.example would override a negative trust anchor for
.example.

This seems to very much be in keeping with the principle of least surprise...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Evan Hunt <[email-masked]>
Date: Tue, 5 May 2015 16:44:49 +0000

> anyone objects, I'll add text to the document stating that.

This matches the BIND implementation.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 5 May 2015 17:06:04 -0400

... and now I'm replying to the rest of the comments.

I've integrated them and posted a new version with the clarifications
on a *positive* **trust anchor** under an NTA.
I'm not very happy with the text I added, if others have better text
happy to consider it...

Huge thanks to Jinmei for the careful review, catching this corner
case, and providing helpful text...

More comments inline.

> a more appropriate choice for me.

I personally don't have a strong opinion here. I think that the
authors figured that it "felt" more informational, and mainly (in our
view) provided advice to operators -- but, we are perfectly happy to
change it to Std if that's what the chairs would like...

> (with some other comments on the 04 version of the draft).

So, I've heard back from some of the other authors (and Evan, one of
the implementors), and what we'd all assumed / understood was what you
also believe is the "right thing". Since the root is signed we haven't
really been seeing many manually configured trust anchors, and so we
hadn't really discussed it much.

If there is a *positive* *trust anchor* for foo.bar.baz.example, it
takes precedence over a negative trust anchor at baz.example. The
mental model I've been using is "just pretend that there is no DS in
the parent" when you see an NTA.

So, now all I need to do is try craft some text (and probably an
example to illustrate).
There are number of places where I'll have to make some changes to
clarify this. I've just posted a new version that somewhat clarifies
this, but more text gratefully accepted...

> it's better to fix them before sending it to the IESG.

Fair. I'll do those. I may post a new version with the larger changes
first, as they may need more discussion.

>   aligned with general tone and other usage of RFC2119 keywords of

DONE.

I now have "It is therefore RECOMMENDED that NTA implementors SHOULD
periodically attempt to validate the domain in question..."
Is that what folk would like?

>    entries below the NTA node.

DONE.
Looks good.

>    configuration "domain-insecure."

DONE.
Weird...

> - Section 7.1: s/has have/has/

DONE.
Good catch.

>    the ability to look at the servers DNS traffic over a long period of

DONE.

>    most of these tools are open source so you can them install locally

DONE.

>    will have more than local view by using different tools.

DONE.

>    consistently around the world and from all authoritative server.s Use

DONE.

>    attack, although that is not an guarantee.  Also if the output from

DONE.
Wow, I didn't do a good proofreading here, did I? :-)

>    EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to

DONE.
Doh!

>    is an indication that the error is operator caused not an guarantee.

DONE.

>    o  DNSKEYs in child zone don't match parents zone DS record.  There

DONE.
Huh. Yeah. I couldn't figure out which, so I made it 'DNSKEYs in child
zone don't match the DS record in the parent zone.'

>       rollover) and of course has the actual data in the zone changes.

DONE. I think.

>    having to decide to deploy or not deploy a trust anchor.

DONE

Thanks for all of the suggestions.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 May 2015 14:53:41 -0700

This document has progressed very well and is nearly ready for publication.

Related to an earlier thread about intended status: "Informational" is most appropriate here because the document is all about proposed operations but no "best current practice". There is no problem with WGs producing Informational RFCs, and Informational RFCs can have RFC 2119 language.

In Section 2, there should be a new paragraph after the first paragraph that describes why the "reasonable attempt" in the first paragraph is needed to determine whether the attacker has partial control of the zone, or is just mounting an on-path attack between all the nameservers and the recursive.

In Section 2, it talks about "a popular domain name" but don't say how to determine that. Giving examples of sources of that data would be valuable.

Section 5 is one paragraph too short. It says what other misconfigurations should not be fixed by recursive resolver operators, but it does not say why likely DNSSEC validation errors should be. The (missing) second paragraph should say something to the effect of "with DNSSEC breakage, it is often possible to tell that there is a misconfiguration by looking at the data and not needing to guess what it should have been".

In Section 6, add a second sentence to the second paragraph: "Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DNSSEC."

In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly called "Altering Users of NTA Use".

There is no stated reason for Appendix B to be an appendix. It is just as important as other sections in the main body of the text, and should be moved there.

References to other documents are done inconsistently. For example, there is both "from RFC4033 [RFC4033]" and "in [RFC5914]".

--Paul Hoffman

---

From: "Rose, Scott W." <[email-masked]>
Date: Wed, 6 May 2015 09:33:46 -0400

I think the draft is just about ready for publication as well.

> In Section 2, it talks about "a popular domain name" but don't say how to determine that. Giving examples of sources of that data would be valuable.
I would recommend local query logs, naturally.  

> In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly calle…
There is a security consideration there, reading between the lines - in that this is broadcasting a spoofable name to the world.  However, a "Altering User's" section would be a good addition to include text about apps that may break if it is known they demand to see the AD bit set in responses.

Scott

===================================
Scott Rose
NIST
[email-masked]
+1 301-975-8439
Google Voice: +1 571-249-3671
http://www.dnsops.gov/
https://www.had-pilot.com/
===================================

---

From: Warren Kumari <[email-masked]>
Date: Wed, 6 May 2015 09:46:55 -0400

[meta comment]

I will be traveling for DNS-OARC, RIPE and another meeting starting this
afternoon. I wanted to mention this so that y'all don't think I'm ignoring
your comments - I really appreciate all feedback, and will integrate
comments in the next couple of days (I like to rev the doc even during
WGLC, so that everyone can see the most recent state, and not comment on
older comments, etc)

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Dan York <[email-masked]>
Date: Wed, 6 May 2015 15:08:00 +0000

Warren and Tim,

I support the publishing of this document subject to incorporating the various comments I’ve seen here on that list. I had a couple of specific points but they seem to have been covered by others,  so…

On May 6, 2015, at 9:46 AM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:

 I really appreciate all feedback, and will integrate comments in the next couple of days (I like to rev the doc even during WGLC, so that everyone can see the most recent state, and not comment on older comments, etc

… I’ll wait for your next version before making any specific comments on the text.  With all the comments coming in I’ve lost track of all the suggested changes.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/<http://www.internetsociety.org/deploy360/>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 6 May 2015 09:51:41 -0700

At Tue, 5 May 2015 17:06:04 -0400,

> ... and now I'm replying to the rest of the comments.

Thanks, I've confirmed that my major and minor points are addressed in
the 05 version.  So I'm now basically fine with shipping it.

Some non-blocking comments follow...

> I'm not very happy with the text I added, if others have better text

The added text looks good enough to me.  If you don't like it
yourself, I might suggest something else, but I'm not sure if it's
obviously better than the current one.  In any case, I think Section 2
is probably a better place to clarify this, partly because that
section has example cases.  But it's not a strong opinion.

Two more related points:

1. In my very original comment on this matter:
   www.ietf.org/mail-archive/web/dnsop/current/msg12614.html
   I noted one other corner case, which we might also want to clarify:
     On a related note, there are some corner cases which may also be
     worth noting: queries for DS or DLV (or anything similar to that).
     So, for example, zone1.example.com/DS should still be validated even
     if there's an NTA for zone1.example.com.  Again, this might sound
     obvious, but I think it's worthwhile.

2. What if both positive and negative trust anchors are specified for
   the same name at the same time?  Maybe it's just implementation
   dependent, and it may or may not be something that is worth
   discussing in this document.

And, here are some other editorial points I happened to notice in this
round of read:

- (this is technical rather than editorial in some sense) Section 4:

   When removing the NTA, the implementation SHOULD remove all cached
   entries below the NTA node.

  Probably s/below/at and below/

- Appendix B: s/do this/to do this/ ?
   There are several tools do this, an incomplete list includes:

- Appendix B: It's better if we can use a different level of bullets
   for these:
   o  DS pointing to a non existent key in the child zone.  Questions...
   o  DS pointing to an existent key, but no signatures are made with...
   o  Data in DS or DNSKEY doesn't match the other.  This is more common...

  since they are sub-bullets of this one:

   o  DNSKEYs in child zone don't match the DS record in the parent
      zone. [...] Common Variations of
      this can be:

  (I don't know if I-D xml allows nested listing though).

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 May 2015 15:07:57 +0200

[ Top post ]
Integrating these -- 'parently I'm processing emails out of order...

Thank you for your comments, I've integrated them and will post a new
version soon (planning on incorporating some of Jinmei's comments
before posting).

> Related to an earlier thread about intended status: "Informational" is most appropriate here because the document is all about proposed operations but no "best current practice". There is no proble…

Thanks.

> In Section 2, there should be a new paragraph after the first paragraph that describes why the "reasonable attempt" in the first paragraph is needed to determine whether the attacker has partial co…

DONE?
"It is important to confirm that the comains is still under the
ownership / control of the legitimate owner of the domain - this is to
ensure that disabling validation for a specific domain does not direct
users to an address under an attackers control. Contacting the domain
owner allows the resolver operator to determine if the issue is a
DNSSEC misconfiguration or an attack."

I'm not really sure if this addresses your concerns? If not, do you
happen to have any suggested text?

> In Section 2, it talks about "a popular domain name" but don't say how to determine that. Giving examples of sources of that data would be valuable.

DONE.
I added: "An example of a list of "top N" websites is the <xref
target="Alexa">"Alexa Top 500 Sites on the Web" </xref>"

Is this OK?

> Section 5 is one paragraph too short. It says what other misconfigurations should not be fixed by recursive resolver operators, but it does not say why likely DNSSEC validation errors should be. Th…

DONE.
I was going to add some hand-wavy bit about the fact that DNSSEC is an
"added feature" and that the behavior differs based upon if you have
turned validation on or not, but this didn't feel helpful, so I just
used your text. Thanks.

> In Section 6, add a second sentence to the second paragraph: "Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DN…

DONE.
Thank you.

> In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly calle…

DONE.
I'm fairly jetlagged, and it took me a silly amount of time to parse
the suggested name :-) Yay autocorrect.

> There is no stated reason for Appendix B to be an appendix. It is just as important as other sections in the main body of the text, and should be moved there.

DONE.
It had felt more "Appendixy" to me, but I don't know why. Moved it
into the body of the doc.

> References to other documents are done inconsistently. For example, there is both "from RFC4033 [RFC4033]" and "in [RFC5914]".

DONE.
Thank you, and apologies for the delay.

W

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 May 2015 15:08:03 +0200

> I would recommend local query logs, naturally.

Oooh! Added.
Thanks.

> There is a security consideration there, reading between the lines - in that this is broadcasting a spoofable name to the world.  However, a "Altering User's" section would be a good addition to in…

Good point. I'm assuming^W hoping that applications that assume a
domain is signed, and expect the AD bit *should* actually be doing
their own validation. But I added this to the security section (it
felt securityish).

"One side effect of implementing an NTA is that it may break client
applications that assume that a domain is signed and expect an AD bit
in the response. It is expected that many application that require
DNSSEC for a domain will perform their own validation, and so this
should not be a major issue."

Is this clear / helpful?

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 May 2015 15:08:06 +0200

On Wed, May 6, 2015 at 5:08 PM, Dan York <[email-masked]> wrote:
> Warren and Tim,
>
> I support the publishing of this document subject to incorporating the
> various comments I’ve seen here on that list. I had a couple of specific
> points but they seem to have been covered by others,  so…
>
> On May 6, 2015, at 9:46 AM, Warren Kumari <[email-masked]> wrote:
>
>  I really appreciate all feedback, and will integrate comments in the next
> couple of days (I like to rev the doc even during WGLC, so that everyone can
> see the most recent state, and not comment on older comments, etc
>
>
> … I’ll wait for your next version before making any specific comments on the
> text.  With all the comments coming in I’ve lost track of all the suggested
> changes.

Yah, fair enough. This is why I like to integrate comments and post
new versions, even during WGLC -- but, I got somewhat behind.... New
version posted, with (I *think*) all comments integrated / resolved.

W

> [email-masked]   +1-802-735-1624
> Jabber: [email-masked]
> http://www.internetsociety.org/
>
>
>

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 May 2015 15:08:11 +0200

> the 05 version.  So I'm now basically fine with shipping it.

Excellent, thank you...

> section has example cases.  But it's not a strong opinion.

Fair -- I also have put text at the bottom of section 2 explaining this.

>      obvious, but I think it's worthwhile.

I have spent some time trying to figure out some text that explains
this without becoming really complex and wordy. If anyone has some
text that they would be willing to send I'd appreciate it...

>    discussing in this document.

DONE.
Oooh. Good point. I believe that this is (probably) something that
implementations should warn about, or refuse. I'll add some text to
say this.

How is:
"It is RECOMMENDED that implementations warn operators (or treat as an
error) if they attempt to add an NTA for a domain that has a
configured positive trust anchor."

>   Probably s/below/at and below/

DONE.
Good catch. Thank you!
>    There are several tools do this, an incomplete list includes:

DONE.
Nice. Thanks.

>   (I don't know if I-D xml allows nested listing though).

DONE.
Whooo! It does! Fixed...

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 9 May 2015 07:33:11 -0700

> happen to have any suggested text?

Using your, expanding just a bit:

"It is important for the resolver operator to confirm that the domain is still under the
ownership / control of the legitimate owner of the domain in order to
ensure that disabling validation for a specific domain does not direct
users to an address under an attacker's control. Contacting the domain
owner and telling them the DNSSEC records that the resolver operator is seeing
allows the resolver operator to determine if the issue is a
DNSSEC misconfiguration or an attack."

> target="Alexa">"Alexa Top 500 Sites on the Web" </xref>"

That's OK, but I would prefer to add in what Scott Rose suggested: ", or a list of the of the most-accessed names in the resolver's cache".

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 9 May 2015 07:38:37 -0700

> text that they would be willing to send I'd appreciate it...

I'm with Warren on this: I can't think of a way to describe this without going into the whole "actually owned by the parent" dance that keeps being hard to describe for everyone.

--Paul Hoffman

---

From: Evan Hunt <[email-masked]>
Date: Sat, 9 May 2015 18:50:28 +0000

> configured positive trust anchor."

You still need to say what happens if the implementation decides to warn
instead of treat it as an error.

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

---

From: Warren Kumari <[email-masked]>
Date: Sun, 10 May 2015 12:08:01 +0200

On Sat, May 9, 2015 at 8:50 PM, Evan Hunt <[email-masked]> wrote:
> May I suggest:
Yes, yes you may...

> "An NTA placed at a node where there is a configured

and I'll go "Yay! Good text" and copy and paste it into the doc....
and that's what I did....

DONE.

W

---

From: Warren Kumari <[email-masked]>
Date: Sun, 10 May 2015 12:08:20 +0200

> DNSSEC misconfiguration or an attack."

DONE.
Oooh, better, thanks....

> That's OK, but I would prefer to add in what Scott Rose suggested: ", or a list of the of the most-accessed names in the resolver's cache".

DONE.
Doh! Because I was integrating many comments in one go (and did
your's, and then Scott's) I'd actually included:
"In the case of a validation failure due to misconfiguration of a TLD
or popular domain name (such as a top 100 website), content or
services in the affected TLD or domain could be inaccessible for a
large number of users. In such cases, it may be appropriate to use a
Negative Trust Anchor as soon as the misconfiguration is confirmed. An
example of a list of "top N" websites is the "Alexa Top 500 Sites on
the Web" , another example would be to look through historical query
logs."
but I'd forgotten to go back and note this here.

Anyway, i think I like yours more, so I'm using yours...

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 May 2015 09:05:12 -0700

At Sat, 9 May 2015 15:08:11 +0200,

> text that they would be willing to send I'd appreciate it...

I didn't think we'd need wordy text to explain this, but I wouldn't be
opposed to omitting this topic from this document.  In practice, it
wouldn't matter much whether we validate zone1.example.com/DS in the
example case since everything else on and under zone1.example.com
won't be validated anyway.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Mon, 11 May 2015 09:10:35 -0700

At Sat, 9 May 2015 18:50:28 +0000,

> 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

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 May 2015 12:19:19 -0400

> keyword (it's probably a SHOULD).

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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 11 May 2015 17:20:08 +0000

>    the coexistence of positive and negative anchors, it should prefer

Good point.  I personally favor A, but would be fine with B.

I'd be interested in input from other implementors; if there's a
constituency for B then fine, but if we're all going to allow
coexistence anyway, we might as well specify it that way.

> keyword (it's probably a SHOULD).

With respect to the precedence rule, I would use MUST rather than SHOULD.

---

From: Evan Hunt <[email-masked]>
Date: Mon, 11 May 2015 17:26:10 +0000

On Mon, May 11, 2015 at 12:19:19PM -0400, Bob Harold wrote:
> I am not even sure there is a good reason for a warning.

In BIND, NTA's are set by an rndc command, but in other implementations
they might be set up in a config file. If you have both a TA and an NTA
for the same node in the same configuration, that would be sensible to
warn about; it's the sort of oddity that might have been unintentional.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 May 2015 11:44:28 +0200

> warn about; it's the sort of oddity that might have been unintentional.

"An NTA placed at a node where there is a configured positive trust
anchor MUST take precendence over that trust anchor, effectively
disabling it. Implementations SHOULD issue a warning or informational
message when this occurs, so that operators are not surprised when
this happens."

Just added. Seem good?

W

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 12 May 2015 12:23:03 +0200

Moin!

> coexistence anyway, we might as well specify it that way.
We (Nominum) currently do A and are fine with it. The text Warren
just sends out with regards to that looks ok, although I would
go with a MAY for the warning. In practice this will not happen
that much as most people configure the root as there only trust
anchor and do NTAs down the tree.

So long
-Ralf

---

From: Evan Hunt <[email-masked]>
Date: Tue, 12 May 2015 15:00:37 +0000

> message when this occurs, so that operators are not surprised when

I'd have gone with MAY instead of SHOULD, but that's a quibble:
it's fine.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 May 2015 17:14:46 +0200

> I'd have gone with MAY instead of SHOULD, but that's a quibble:

Changed.

This gave me an excuse to bump the version number to -10, which
scratches my OCD itch.
:-)

W

---

From: 神明達哉 <[email-masked]>
Date: Tue, 12 May 2015 10:55:14 -0700

At Tue, 12 May 2015 11:44:28 +0200,

> message when this occurs, so that operators are not surprised when

In the sense of (my understanding of) Evan's point, it would probably
be even better if we explicitly clarify the coexistence of positive
and negative anchors should be allowed.  So how about:

   An implementation that supports NTA SHOULD allow users to configure
   both positive and negative trust anchors for the same name at the
   same time.  In this case, the NTA MUST take precedence over that
   positive trust anchor, so the NTA can be used as a way to disable
   DNSSEC validation for a specific name space temporarily.
   Implementations MAY issue a warning or informational message when
   this occurs, so that operators are not surprised when this happens.

(btw, my Emacs noticed a typo in the original text and I fixed it above:
 s/precendence/precedence
 this fix should be applied even if my proposed text is rejected)

--
JINMEI, Tatuya