If I remember the discussions correctly, there was a sense that the
resolver decides the local policy. And that yes, those are the three
options. Perhaps the options should be made more clear in a text somewhere.
On Tue, 31 Oct 2017, Ólafur Guðmundsson wrote:
There are three ways to treat this case:
Any-TruestedKey-works
ConfiguredKey-trumps-DS
DS-trumps-configuredKey
I think the Last one is the "most" correct from an operational expectation,
but the first one is least likely to run into errors,
But I suspect the middle one is implemented
Olafur
On Tue, Oct 31, 2017 at 2:39 AM, Moritz Muller <moritz.mul...@sidn.nl>
wrote:
Hi,
Together with my colleagues I have been stumbling upon a, for me, unclear
case when validating trust anchors.
Assuming that a resolver has enabled DNSSEC validation and has the root
keys configured.
Additionally, it has configured manually a trust anchor for a TLD (that
has also published its DS in the root zone).
Now, for example due to a key rollover at the TLD, the manually configured
trust anchor of the TLD does not match the DS in the root anymore.
How should a resolver treat the signatures of this TLD?
The resolvers of BIND, Unbound, and PowerDNS seem to treat the signatures
of the TLD as bogus, but we didn't find any specifics in RFC 4034 and 4035
that describe how resolvers should behave in this case.
Knot resolver treats them as NOERROR (according to the developers).
If we interpret section 4.3 of RFC 4035 then we would have assumed that
the signature must be treated as secure.
Did we miss something, or is there indeed clarification needed?
— Moritz
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
