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

["Mark Delany" <[e-mail]>]

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

I'm not sure I see the distinction between disallowing unexpected HTTP
parameters - as you recommend - and disallowing unexpected DNS parameters -
which I presume you don't recommend.

> So in short, I would not go out and recommend that servers simply ignore
> unknown parameters. They might accidentally do it but it fosters bad things
> like silent errors & even more tracking than cookies, TLS resumption tickets
> and HTTPS agent headers already bring.

I sympathize with the problem and like many here I too have been on the
receiving end of protocol implementations which were far too lax in what they
sent/accepted. But you're effectively recommending that DoH shouldn't use the
extension mechanisms built into HTTP. At that point you have to ask whether it's
even HTTP any more.

A related problem is that most DoH implementors probably rely on pre-existing
HTTP componentry rather than rolling their own from scratch. Said componetry is
notorious for adding headers without necessarily giving the application much
control over it. After all, it's worked fine for the last 20+ years, why stop
now? So at least on that front I think the horse has well and truly bolted.


I suppose one could go down the path of a DoH HTTP profile or version but most
internet protocols seem to shy away from the strictures of profiling and
versioning - perhaps because upgrades tend to turn into monumental events.


I don't think there's ever been a good solution to this dilemma: accepting
unknown parameters is a protocol risk yet accepting unknown parameters is also
the preferred mechanism for version interop.


Mark.