1.1.1.1 Malformed (but technically valid) response TLS 1.3

DNS & Network 1.1.1.1
#1

Hello, I am building a DNS proxy and was testing it against different providers. While doing this, I noticed an anomaly with responses from 1.1.1.1 over TLS 1.3, specifically, a lot of extra zero bytes as well as some junk data at the end of the response. This does not happen with other resolvers, like Google.

Here is the content of the exact request sent over TLS 1.3 (TLS13_AES_256_GCM_SHA384) to 1.1.1.1:853, bytes are in hex:

[52, 88, 81, 80, 0, 1, 0, 1, 0, 0, 0, 1, 3, 77, 77, 77, 4, 61, 73, 64, 66, 3, 63, 6F, 6D, 0, 0, 1, 0, 1, C0, C, 0, 1, 0, 1, 0, 0, 0, 9B, 0, 4, 40, 5A, 28, 41, 0, 0, 29, 4, D0, 0, 0, 0, 0, 0, 0]

This is a lookup request for “www.asdf.com”

1.1.1.1 then responds with a 470 byte response:

[1, D4, 52, 88, 81, 80, 0, 1, 0, 1, 0, 0, 0, 1, 3, 77, 77, 77, 4, 61, 73, 64, 66, 3, 63, 6F, 6D, 0, 0, 1, 0, 1, C0, C, 0, 1, 0, 1, 0, 0, 0, 9C, 0, 4, 40, 5A, 28, 41, 0, 0, 29, 4, D0, 0, 0, 0, 0, 1, 9B, 0, C, 1, 97, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

This parses as a correct response, but it also contains extra bytes “0, C, 1, 97” then a bunch of zeroes.

This is the expected response:

[0, 39, 52, 88, 81, 80, 0, 1, 0, 1, 0, 0, 0, 1, 3, 77, 77, 77, 4, 61, 73, 64, 66, 3, 63, 6F, 6D, 0, 0, 1, 0, 1, C0, C, 0, 1, 0, 1, 0, 0, 0, 9B, 0, 4, 40, 5A, 28, 41, 0, 0, 29, 4, D0, 0, 0, 0, 0, 0, 0]

Notice the similarity with what the long response from 1.1.1.1. The main difference being the first two bytes, which signify the length of the data to follow (0x39 = 57 bytes), and the above pointed out extra bytes and zeroes.

Can someone look into this?

1 Like
#2

I’m doing some work to verify my findings. Will confirm this later tonight / tomorrow one way or another.

#3

Alright, I took a look and it does appear 1.1.1.1 is sending extra bytes. This seems significant in the sense that a lot of extra data is being sent that doesn’t need to be, which probably puts extra load on the server, is slower, costs more in bandwidth… etc.

Anyone want to investigate? I can provide more data if needed. It should be pretty easy to check though. This doesn’t happen when using unencrypted DNS to 1.1.1.1:53.

Steps:

  1. Connect to 1.1.1.1:853 over TLS 1.3 (I didn’t check any others)
  2. Complete handshake
  3. Send query for ‘www.asdf.com’
  4. Read response bytes (do not parse) from socket
  5. Check length of response bytes (I receive a valid response with a total of 470 bytes, mostly zeroes, should be ~59 total bytes including the first two bytes representing the length of the TCP DNS response)
#4

Hi! This is called padding. See RFC 8310 - Usage Profiles for DNS over TLS and DNS over DTLS RFC 7830 - The EDNS(0) Padding Option and RFC 8467 - Padding Policies for Extension Mechanisms for DNS (EDNS(0)).

4 Likes
#5

Thanks for the explanation! I had no idea that was a thing, but after reading the RFC it makes sense. The more you know…

#6

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