[dns-operations] Problems resolving .gov using DLV

[Florian Weimer]

* Ondřej Surý:

>> * Keith Mitchell:
>>
>> > Thanks Michael for flagging this up. When specing DLV the possibility
>> > that a TLD submitting trust anchors to DLV might use only NSEC3 for
>> > signing it, when many servers out there do not support NSEC3, was
>> > clearly overlooked.
>>
>> I don't think it's a DLV issue.  It's required by RFC 4035:
>>
>> | 5.5.  Resolver Behavior When Signatures Do Not Validate
>> |
>> |    If for whatever reason none of the RRSIGs can be validated, the
>> |    response SHOULD be considered BAD.  If the validation was being done
>> |    to service a recursive query, the name server MUST return RCODE 2 to
>> |    the originating client.  However, it MUST return the full response if
>> |    and only if the original query had the CD bit set.  Also see Section
>> |    4.7 on caching responses that do not validate.
>
>
>
> Nope.
>
> See 5.2:
>
>    If the validator does not support any of the algorithms listed in an
>    authenticated DS RRset, then the resolver has no supported
>    authentication path leading from the parent to the child.  The
>    resolver should treat this case as it would the case of an
>    authenticated NSEC RRset proving that no DS RRset exists, as
>    described above.

And 5.2 trumps 5.5?  I wouldn't count on that.  RFC 4033 lists the
"unsupported algorithm" case along with things which are clear
validation failures (and which should not trigger fallback to insecure
state):

|   Insecure: The validating resolver has a trust anchor, a chain of
|      trust, and, at some delegation point, signed proof of the
|      non-existence of a DS record.  This indicates that subsequent
|      branches in the tree are provably insecure.  A validating resolver
|      may have a local policy to mark parts of the domain space as
|      insecure.

|   Bogus: The validating resolver has a trust anchor and a secure
|      delegation indicating that subsidiary data is signed, but the
|      response fails to validate for some reason: missing signatures,
|      expired signatures, signatures with unsupported algorithms, data
|      missing that the relevant NSEC RR says should be present, and so
|      forth.

So I would say that the spec is ambiguous at best.