Skip to main content

Definition and Use of DNSSEC Negative Trust Anchors


Alvaro Retana
(Joel Jaeggli)
(Kathleen Moriarty)

No Objection

(Alia Atlas)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)

Note: This ballot was opened for revision 10 and is now closed.

Alvaro Retana
Joel Jaeggli Former IESG member
Yes (for -10)

Kathleen Moriarty Former IESG member
Yes (for -10)

Stephen Farrell Former IESG member
Yes (2015-07-09 for -10)
In an ideal world, my YES ballot for would really be "YES,
sadly I suppose we need this kind of thing but wouldn't life be
much better if DNSSEC was much easier to deploy, ah well, too
late now I guess:-(" 

- section 1.1: Where is the definition? I see you telling me
what an NTA isn't, but not what it is. I think what you want to
say is that an NTA is a domain name or a pair (a domain name
and a sub-domain of that) represented in a resolver
implementation-specific manner so that DNSSEC validation is
turned off from the higher domain name down (to the subdomain
if we have a pair). Is that right?

- 1.1: RFC5914 is a little misleading as a reference as that
was done for X.509 stuff and is nothing to do with DNSSEC.
Maybe it'd be worth pointing that out just in case some reader
somewhere goes and gets confused.

- section 2: what do you mean happens "once per quarter"?

- section 2: "immediately restores" - well that depends on the
screw-up doesn't it? Or are you saying (where?) that an NTA
must only be put in place when the screw-up is specifically and
only about and because of DNSSEC and where ignoring DNSSEC will
result in things "working"? For example, DNSSEC could fail
because all my nameservers are entirely offline due to a f/w
mis-configuration that blocks loads of port 53, but putting in
place an NTA won't help then. (As it happens, I'm right now
gettting a f/w to re-unblock 53 so I can serve some DNSSEC
records so this issue is one that's close to the bone for me:-)

- Section 6: 1st 2 sentences repeat repeat
too too many times.

- random question: why not have an "I'm just testing" RR that I
could put in alongside my ZSK DNSKEY as I start to play with
DNSSEC? Or maybe that exists already.
Alia Atlas Former IESG member
No Objection
No Objection (for -10)

Alissa Cooper Former IESG member
No Objection
No Objection (2015-07-08 for -10)
= Sec 2 =

"Technical personnel trained in the operation of DNS servers MUST
   confirm that a failure is due to misconfiguration"

s/MUST/must/ - seems odd to put a normative requirement on people to do something in people land

= Sec 4 =

"The lifetime MUST NOT exceed a week. "

Would be good to provide the motivation for where this number comes from.
Barry Leiba Former IESG member
No Objection
No Objection (for -10)

Ben Campbell Former IESG member
No Objection
No Objection (2015-07-08 for -10)
-- General:

This is just an observation, since this is informational draft. I do not expect or suggest any action on it. (But if it had been standards or BCP track, I might have made it a discuss.) If I understand this correctly, it suggests that resolvers be configured to stop validating known broken names. This of course has the risk of circumventing the protection that a domain intended by using DNSSEC in the first place. The draft does discuss those risks. But I would have been happier to have seen something with a tone more along  "We know you are going to do this thing, and it's probably better than globally switching to a non-validating resolver-- so here's the risks, and here's some ways to minimize those risks" (which I think might have been good BCP material)  rather than "This is a good practice to work around broken DNSSEC configurations." 

-- section 1.2, last paragraph, last sentence:
Out of curiosity, has this been an issue?

-- 2, 2nd paragraph:
Can an operator be reasonably expected to be able to confirm that a domain is being operated by its rightful owner?

-- 2, 2nd to last paragraph:

Since the requirement to limit the time an NTA is used is a MUST, it seems like the ability to configure that time should also be a MUST.

-- 2, last paragraph:

Why is the requirement not to affect another branch weaker than the requirement not to affect other names higher up the same branch?

-- 4, first paragraph, last sentence:

This seems to favor erring on the side of keeping the NTA. I think security would suggest erring on the side of removing the NTA.

Editorial and Nits:

-- If you plan to use capitalized 2119 terms, please add the appropriate boilerplate and a 2119 reference.

-- section 4, first paragraph: "It is therefore RECOMMENDED that NTA implementors SHOULD"
redundant 2119 keywords (RECOMMENDED and SHOULD )

-- 7, paragraph 4, last sentence:
I suggest adding “At the time of this writing…”, and add additional text to remind people these may change over time.

-- 7:
This section  jumps into 2nd person. I don’t want to stand on formality, but it would be good to keep a consistent tone across the draft.
Benoît Claise Former IESG member
No Objection
No Objection (for -10)

Brian Haberman Former IESG member
No Objection
No Objection (for -10)

Deborah Brungard Former IESG member
No Objection
No Objection (for -10)

Jari Arkko Former IESG member
No Objection
No Objection (for -10)

Martin Stiemerling Former IESG member
No Objection
No Objection (for -10)

Spencer Dawkins Former IESG member
No Objection
No Objection (for -10)

Terry Manderson Former IESG member
No Objection
No Objection (2015-07-07 for -10)
Thank you for a well written document. Many more thanks for using github and making commit comment changes there!!