Hi, thanks for the response. Comments inline--I've deleted text that
doesn't seem to require further discussion.
Ben.
On 8 Jul 2015, at 21:59, Warren Kumari wrote:
On Wed, Jul 8, 2015 at 2:08 PM, Ben Campbell <b...@nostrum.com> wrote:
Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-negative-trust-anchors-10: No Objection
Thank for you review. I have posted a new version in github at
https://github.com/wkumari/draft-livingood-dnsop-negative-trust-anchors
[...]
-- section 1.2, last paragraph, last sentence:
Out of curiosity, has this been an issue?
Erm, I'm a bit lost -- Section 1.2 is only really a header. I'm not
sure if you mean section 1.2.1, last paragraph, last sentence or
1.2.3, last paragraph, last sentence. Both are true / have been
issues.
If 1.2.1:
"For example, it is conceivable that a domain may be DNSSEC signed
properly, and one vendor's DNS recursive resolvers will validate the
domain but other vendors' software may fail to validate the domain."
Yup, this has happened a few times -- there are part of the DNSSEC
specs that e.g BIND and Unbound interpreted (or implemented)
differently.
An example:
http://comments.gmane.org/gmane.network.dns.bind.user/49875
That one, sorry. Thanks for the reference.
[...]
-- 2, 2nd paragraph:
Can an operator be reasonably expected to be able to confirm that a
domain is being operated by its rightful owner?
In many cases, yes. For example, if the website says: "Hacked by
Syrian Electronic Army"
(http://arstechnica.com/security/2015/06/us-army-website-defaced-by-syrian-electronic-army/)
you can be fairly sure it is *not* being operated by the rightful
owner :-)
:-)
More seriously, usually you *can* tell -- for example, if the
signatures have expired but everything else remained the same it is
likely operated by the rightful owner. Also, during the recent .ke
(Kenya) DNSSEC issue (
http://ianix.com/pub/dnssec-outages/20150331-ke/ ) various people were
in contact with the ccTLD operator. There are also various things like
passive DNS services which keep historical data on things like
nameservers. If the NS hasn't changed, you can be fairly sure it is
being operated by the owner...
Okay. I accept that an operator can make reasonable decision here in
many cases.
-- 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.
Hmmm.... I'm not sure I agree. The document says:
"NTAs MUST expire automatically when their configured lifetime ends.
The lifetime MUST NOT exceed a week. "
An implementation *could* always install one for a week, and the
operator could remove it before it automatically expires. If I'm
installing one I would install it for the full week and then check it
every few hours, and remove it before it expires. I cannot think of a
scenario where I'd know ahead of time that the problem will be all
solved in e.g 3 days, and so choose a shorter lifetime. If I *did*
think it would be solved in 3 days I'd still set it for a week and
then have a calendar reminder / bug in my bug tracking system that
went "Ping" to make me check it manually. Having the NTA expire before
the issue is resolved makes the domain go bogus again, and users
become frustrated...
Okay.
-- 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?
You may have an example like:
example.net IN NS ns1.example.com
If I install an NTA for example.com (and so make ns1.example.com alive
again) example.net will now work again, so fixing something in one
branch affects something in another branch.
Ah, I hadn't considered that case.
What we are do not want to have happen is that installing an NTA for
example.com disables validation for .com -- it is probably possible
that something like:
.com IN NS foo.bar.example.com
and foo.bar.example.com becomes bogus. Installing an NTA *does* now
affect names higher in the tree, but this is (I think) pathological
and not worth trying to address.
Agreed.
-- 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.
I think it is actually more of a stability / "know what you are doing
before mucking with stuff" argument. The next sentence says:
"Once all testing succeeds, an NTA should be removed as soon as is
reasonably possible."
It you ends up in a situation where e.g the master is serving good
data, but the 3 slaves are all serving expired signatures and the
operator happens to query the master and remove the NTA you may end up
in a situation where 3/4 queries die and 1/4 succeed. This will end up
creating user confusion and a very difficult to debug situation.
The above is mainly a "hey, before removing an NTA, make sure you
aren't shooting yourself in the foot" reminder.
After re-reading some of the other text about determining when to remove
an NTA, I'm okay with this.
[...]
-- 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.
Good point. I changed it to:
"At the time of this writing are several tools to do this, including:
DNSViz (http://dnsviz.net)
Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com)
zonemaster (http://www.zonemaster.fr,
https://github.com/dotse/zonemaster)
most of these tools are open source and can be installed locally.
However, using the tools over the Internet has the advantage of
providing visibility from a different point. This is an incomplete
list, and it is expected that additional tools will be developed over
time to aid in troubleshooting DNSSEC issues.
"
That works for me.
[...]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
