Re: [Doh] [Ext] DoH client-server interoperability vs. strict HTTP parameter checking

[Joe Abley <[e-mail]>]

Hi Mark,

On 2 Jun 2019, at 08:17, Mark Delany <[e-mail] <mailto:[e-mail]>> wrote:

>> And in the DNS world we've often let clients know we don't get their
>> newfangled speak (FORMERR).  Silently ignoring unexpected parameters is a
>> great way to proliferate half-working configurations.  "Did
>> parentalcontrol=0&malwarefilter=1 get accepted or not?  I have no idea".
> 
> There are certainly pros and cons to this as well as many counter-examples.
> 
> Haven't we just spent the last decade trying to encourage things like caches,
> forwarders and firewalls to accept and pass thru DNS RR types they don't
> recognize?

I'm not sure that's actually a particularly good example. New RRTYPEs are not new parameters or new protocol elements; they're existing ones with different code-points. The distinction is important. To the kinds of intermediate actors you mention, wire-format RRSets ought to be passed through as opaque structures.

> After all, how would we ever extend DNS if every component rejected
> every RR type and OPT sub-type it didn't understand?

EDNS is a better example, since RFC 6891 makes it clear that unknown options MUST be ignored.

In the very general sense (ignoring protocol specifics relating to the DNS and HTTP) it feels like it might be handy to be able to specify a capabilities requirement with a query. Something like

 - I want an answer to the question PIR.ORG/IN/SOA <http://pir.org/IN/SOA> with RD=1
 - I want query minimisation and secure transport for recursive queries
 - I want you to confirm explicitly that you understand the request for query minimisation

A receiving server could ignore the request for secure transport if it didn't understand it, but would refuse to process the query if it didn't understand query minimisation (and hence would otherwise silently discard the request).


Joe