Proposal: Convey Extended DNS Errors
bemasc opened this issue · 10 comments
RFC 8914 defines "Extended DNS Errors", which are more detailed explanations for why a DNS lookup failed. For example, instead of just learning "SERVFAIL", the client might also receive EDE Code 12, "NSEC Missing", which explains what the problem is with the zone's DNS configuration.
Although most EDE errors are expected to accompany a "SERVFAIL" response, some can also appear alongside a successful DNS response, e.g. EDE Code 3, "Stale Answer". EDE also allows DNS servers to send EXTRA-TEXT, a free-text explanation of the error.
I don't know what the best way to encode this would be. Perhaps a new top-level field like:
"extended_dns_error": {"code": 12, "extra_text": "..."}@ericorth FYI
I think this is a great idea! If we are open to considering more detailed errors, we might also want to consider proxy status code errors.
This can expose details of DNS server / client the user is using. I don't think that would be acceptable.
Hmm, can you drill in on that a bit more? Certainly NEL shouldn't reveal any new information that isn't already available to the RP.
What do you mean by "RP"? I don't believe there is any web API that allow scripts to inquiry DNS server directly or learn of extended DNS errors encountered while resolving a host name via DNS. If there is, we'd probably consider that as a security/privacy bug that we need to fix.
What do you mean by "RP"?
Sorry, I mean the thing you send reports to.
I don't believe there is any web API that allow scripts to inquiry DNS server directly or learn of extended DNS errors encountered while resolving a host name via DNS.
I'm not really following you, but I'll reply with a couple points:
- There are non-web cases where NEL may be useful.
- I consider these reports somewhat akin to Client Hints, in that clients can simply choose to not supply a hint if they don't want to support it. So while it may not be appropriate in a web context, there may be other (first party) use cases where it is entirely appropriate.
- The current contents of a NEL report already include information that might be particular to a user's DNS configuration. For example, if DNS fails because the domain was filtered, that reveals information about a give user's setup, right? As above, we should certainly not expose any new information beyond what NEL already exposes. But this extended set of errors does not, to me, yield anything substantially new. Part of the disconnect here may be that I don't know what your threat model is.
Part of the disconnect here may be that I don't know what your threat model is.
The best description of our threat model that I'm aware of is in §3.2 of our NSDI paper on NEL. In brief, NEL cannot give the site operator any more information than they could get from server-side monitoring. That's why (for instance) we don't include the client's resolver address in NEL reports about DNS errors.
The best description of our threat model that I'm aware of is in §3.2 of our NSDI paper on NEL. In brief, NEL cannot give the site operator any more information than they could get from server-side monitoring. That's why (for instance) we don't include the client's resolver address in NEL reports about DNS errors.
Great! That matches my mental model for this too.
There are non-web cases where NEL may be useful.
As in a non-browser context?
I consider these reports somewhat akin to Client Hints, in that clients can simply choose to not supply a hint if they don't want to support it. So while it may not be appropriate in a web context, there may be other (first party) use cases where it is entirely appropriate.
This is also outside web browsers?
The current contents of a NEL report already include information that might be particular to a user's DNS configuration. For example, if DNS fails because the domain was filtered, that reveals information about a give user's setup, right? As above, we should certainly not expose any new information beyond what NEL already exposes. But this extended set of errors does not, to me, yield anything substantially new. Part of the disconnect here may be that I don't know what your threat model is.
That would be a pretty serious privacy issue to me. It's likely a show stopper issue for WebKit.
It might be helpful if you elaborated on the privacy issue given (a) clients are not required to send any particular value and (b) the errors in the document Ben references are sometimes resolver agnostic.
Just to clarify,
In brief, NEL cannot give the site operator any more information than they could get from server-side monitoring.
this does not apply to DNS errors, right?