Abstract (and Section 2):
Please remove the acronym DRO and just use "operator".
Section 3 (Introduction):
The first two paragraphs of the Introduction can be removed.
Section 4 (Time Recommendations)
This section repeats a lot and could be cut.
But a real issue I have is with recommending a hardcoded IP for NTP
service lookup. There are other mechanisms available for getting a rough
time estimate. For example, looking at the RRSIG of the SOA of the root
zone, maybe augmented with a querying a semi random name in a large zone,
eg .com and check the RRSIG on the NSEC(3) record. Another method could
be to just disable validation and take the NTP dns entry without DNSSEC,
and once proper time is obtained, flush the entire cache or restart
the validator.
To me, it seems anything is better than hardcoding an IP address.
Upon demand: a DNSSEC validator operator ought to be able to
perform any of the runtime actions upon demand, for instance,
to help diagnose a service failure.
I don't understand what this sentence is saying.
Section 5:
I'm not sure we want to recommend 5011 to operators for anything but the
root zone (and maybe not even for that). Regardless, I think the entity
needing to solve the freshness of TA issue is not the operator, but the
domain that requires its own seperate TA. So lets say that .mil wants it
internal resolvers to hardcode the .mil TA, it needs to provide the method
for keeping their TA fresh. The operator merely needs to follow that
published method. I'd say that would be out of scope for this document.
This section should also discuss split-DNS deployments and how that
affects TA's and how to avoid sending public answers to the private side
and visa versa.
Section 6:
Negative Trust Anchor (NTA) represents the only permitted
intervention in the resolving process for a DRO.
Why shouldnt an operator be able to flush a zone to get rid of say, a bad
RRSIG record in the cache to reduce the downtime caused by a deployment
error on the authoritative server. Another common method is to allow records
beyond their signature expiry time to be served while attempting to refresh
the record in the background. NTAs are not the only permitted intervention.
Section 7:
A common concern DRO has is the consistency between
the cached RRset with those published by the DNS
system. DRO should not implement or deploy any non standard
mechanism. [I-D.ietf-dnsop-ns-revalidation] is one of these
mechanisms
Is this draft saying to not implement I-D.ietf-dnsop-ns-revalidation ?
In such a situation, the DRO should be able to remove the RRsets
validated by the rogue DNSKEY - which may be done by flushing
the full cache.
Why flush the full cache? Why not just the subtree for which the DNSKEY
is authoritative? Eg if DNSKEY nohats.ca. is rogue, why not just flush
"nohats.ca." and everything below that?
Section 8:
a DNSSEC validator may be willing to estimate the impact of deprecating
one signature scheme.
I don't understand what this is trying to say,
Section 9:
I'm not sure if this is actionable at all. Its like telling me to read
all my syslog of all my servers. It's just not going to happen. too
many noisy logs and background attacks happening for me to respond.
Section 10:
I believe all of this should not be the responisbility of the operator,
but of the DNS software. It should do the right thing.
Section 11:
A DRO should consider secure transport as a complementary element of
its trust model.
I strongly object to calling encrypted transport "secure transport" and
thus implicitly calling unencrypted transport "insecure". With DNSSEC,
there is no security issue with going over unencrypted transport. There
might be a privacy issue, but not a security issue.
Section 12:
A DRO should consider how the DNS client will discover the encrypted
resolver.
We have a whole can of worms in the ADD WG about this. Not sure we should
repeat those discussion in this draft.
To ease the (even future) deployment of DDR, it is recommended
that a DRO uses a global IP address for its unencrypted resolver.
Most DNSSEC validators are behind NAT on their own private IP space. I
dont think this draft should recommend those somehow get public IPs.
Section 13:
As a result, when the time is outside this period validation
is disabled, and this could be used by an attacker to disable
validation for example to poison the cache
Why is validation disabled? Validation failure and ServFail means there
is no attack possible. If for validation only the TTL and RRSIG lifetime
is ignored, there is still no chance to poison the cache with anything
other than the content of the cached record, which validated at the time
of retrieval.
an attacker being able to provide a rogue trust anchor is potentially
This is not a very realistic attack.
Using weak cryptography reduces the strength in the trust
implemented by DNSSEC as it relied on cryptographic signatures.
That is mostly a problem of authoritative servers. The validator has no
choice but to either use the weak algorithm that is in use, or worse treat
it as unsigned. So there isn't anything a resolver operator can do here.
it is recommended a DRO relies on different vendors.
While I understand the argument, a counter argument could be made too. By
using different vendors, one becomes victim to all implementation bugs,
instead of just the ones from one vendor. Which is better? Perhaps
chaining two vendors would be better? Regardless, I think this
recommendation is not very good for resolvers. It applies better to
authoritative servers.
the TLS communication enables the DNS client to trust the RRSets
without performing a DNSSEC validation.
I strongly object to saying that transport security can be used to replace
data origin security. Encrypted DNS does not obsolete DNSSEC.
The trust in a DNS resolver depends on multiple factors, but one
significant concern is the ability of the DRO to perform a man
in the middle attack and change on the fly the RRsets without
the stub client being aware of it.
Exactly! So you MUST RECOMMEND using DNSSEC to prevent this attack.
Missing from this document:
- Operator considerations with multiple resolvers in their network and how
to best operate them
- Experience of how we dealt with previous DNSSEC specific outages
- Advise on how to debug/detect DNSSEC issues
- Split DNS considerations
- VPN considerations
I don't think this document contains much valuable content for a DNSSEC
operator. I think this document needs to have resolver vendors with
their customer support experiences involved in evolving this document.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
