DoH serverTokens: duplicate server header and ignored setting

[appliedprivacy]

• Program: dnsdist
• Issue type: Bug report

Short description

There are actually 3 issues but since they are closely related we'll document them in one go:

a) ignored serverTokens value

Setting the serverTokens option via
addDOHLocal( ..., "/query", { serverTokens='abc'})

has no effect on the HTTP server header field for HTTP requests not going to /query.

b) duplicate HTTP server header

Setting the serverTokens option via
addDOHLocal( ..., "/query", { serverTokens='abc'})

causes the server to send multiple HTTP server headers:

HTTP/2.0 200 OK
server: h2o/2.2.5
date: Fri, 07 Jun 2019 18:17:52 GMT
server: abc
content-type: application/dns-message
content-length: 80
X-Firefox-Spdy: h2

when the client issued a valid DoH request.

c) documentation issue

The documentation says the default value for serverTokens is h2o/dnsdist
but it is actually h2o/<h2oversion> currently that is h2o/2.2.5

Environment

• Operating system: Debian Buster
• Software version: 1.4.0~beta1-1pdns.buster
• Software source: PowerDNS repository

Steps to reproduce

a)
curl -si https://doh.appliedprivacy.net

b)
curl -si "https://doh.appliedprivacy.net/query?dns=l1sBAAABAAAAAAAAA3d3dw1rbm90LXJlc29sdmVyAmN6AAAcAAE"

c)
https://dnsdist.org/reference/config.html#addDOHLocal

Expected behaviour

• dnsdist should set the HTTP server header to h2o/dnsdist by default (as per documentation)
• dnsdist should set the HTTP server header to the value provided in the serverTokens option (no matter which URL the client requested)
• dnsdist should not send multiple HTTP server header

Actual behaviour

• dnsdist ignores the serverTokens option complete when answering HTTP requests that are not valid DoH requests
• dnsdist sends multiple HTTP server header when the request is a valid DoH request and the configuration contains the serverTokens option

[rgacogne]

Thank you for reporting this!
The a/ issue is clearly an oversight on my part, I guess we could make sure that we route all queries by registering "/".
The b/ and c/ issues depend on the version of libh2o, as it seems that some versions allow overriding the "Server" header and some don't. I'll investigate.