DoH is not preserving the DNS Message ID


#1

Cross-posting from https://github.com/jedisct1/dnscrypt-proxy/issues/501 .

It appears that recently the Cloudflare DoH server has stopped preserving the Message ID (first 16 bits of DNS wire format) and is responding with 0x00 instead.

It can be reproduced by sending a GET or POST DoH query:

# Encode question with message ID 0xCAFE
>>> p = binascii.unhexlify(b'cafe0100000100000000000100000200010000291000000080000000')
>>> base64.urlsafe_b64encode(p)
b'yv4BAAABAAAAAAABAAACAAEAACkQAAAAgAAAAA=='
# Response is received with message ID 0x00
$ curl -s "https://1.1.1.1/dns-query?ct&dns=yv4BAAABAAAAAAABAAACAAEAACkQAAAAgAAAAA==" --output - | xxd
00000000: 0000 81a0 0001 000e 0000 0001 0000 0200  ................
00000010: 0100 0002 0001 0000 17c0 0014 0161 0c72  .............a.r
00000020: 6f6f 742d 7365 7276 6572 7303 6e65 7400  oot-servers.net.
<rest of response omitted>

This has broken dnscrypt-proxy and I suspect other implementations.

Is it possible to find out whether this is an intentional change?


#2

Hi, this is my fault, I made a change recently to clear it for HTTP cache friendliness, and didn’t realize clients depend on it (which is fine, since different message ID is permitted). I’ll roll back the change.


#3

Thanks a lot Marek!

dnscrypt-proxy always uses DNS ID 0 except for the very first query, which is just a probe to check that we are talking to something that actually resembles a DoH server.

Checking that we get the correct ID back was just a dumb way to do it, and since the specification still has a SHOULD for it being 0, I explicitly picked something else to reduce false positives.

Verifying only the first bytes of the response was just me being lazy. I’m going to improve that to actually verify that the whole response looks like DNS records. The query ID for that probe will then be set to 0 like everywhere else.

Anyway, thanks a ton for rolling back that change meanwhile. You rock!


#4

No problem, it was my mistake anyway, thanks for looking into this!


#5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.