Tony Finch <d...@dotat.at> writes:
> I have had another read through.
Thanks for the extra pass.
(we still have IETF-wide last call to wade through too, FYI)
> In the intro, one of the example uses for EDE is a server returning errors
> because it has not finished starting up, but there is no EDE code for this
> case.
It's this one:
3.15. Extended DNS Error Code 14 - Not Ready
The server is unable to answer the query as it is not fully
functional (yet).
> Re. EDE 0 "other", is it supposed to cover the situation when there are
> multiple errors, e.g. different authoritative servers have different
> problems?
One, the latest version talks about servers MAY put in more than one
EDE. But 0/other was "not in the list", IE there is not currently
defined code that would help me but I want to include an error message
that better describes it in the text section.
> Re. EDE 5 indeterminate, RFC 4035 says:
>
> Indeterminate: An RRset for which the resolver is not able to
> determine whether the RRset should be signed, as the resolver is
> not able to obtain the necessary DNSSEC RRs. This can occur when
> the security-aware resolver is not able to contact security-aware
> name servers for the relevant zones.
>
> Is this not also covered by EDE 9 (DNSKEY missing) and EDE 10 (RRSIG
> missing)?
>
> [ I'm still not convinced "indeterminate" is a coherent validation state... ]
I think you're irght that 9/10 are specific cases of indeterminate.
There might be implementation specific reasons too, though, so 5 is a
fallback if you don't have anything more specific (and 0 is a fallback
from that :-) ). Anyway, I've always hated the indeterminate marking
because I agree it's incomplete and conflicts in definition between the
two rfcs. I've devoted multiple slides in presentations to that issue.
> Re. EDE 11 no DNSKEY zone bit, why is there a special case for this and
> not for DNSKEY protocol not equal to 3? Are either of these errors that
> anyone has seen in the wild? (If so I would love to know how that came to
> pass!)
It was suggested to be added, so I did. It does make some sense... but
no, I've never seen it in the wild either.
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
