Page MenuHomePhabricator

Wikidough: Support EDNS(0) Padding: RFC 7830 and RFC 8467
Open, Needs TriagePublic

Description

RFC 7830 describes the EDNS(0) Padding Option that pads DNS queries and responses to prevent size-based correlation of encrypted DNS messages. The policies and their specific details are further described in RFC 8467. Given that Wikidough supports DoT and DoH, it will be good to have (read: we should have) support for padding responses to further improve the privacy of DNS responses over an encrypted channel, specifically, between the stub and the recursor.

Wikidough does not currently support padding:

;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 6717
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; example.com.        		IN	A

;; ANSWER SECTION:
example.com.        	86400	IN	A	93.184.216.34

;; Received 56 B
;; Time 2021-02-10 15:22:39 EST

But it should (from another resolver that supports it):

;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 46138
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.        		IN	A

;; ANSWER SECTION:
example.com.        	65875	IN	A	93.184.216.34

;; Received 468 B <-- as specified in RFC 8467, response padded to 468 bytes
;; Time 2021-02-10 15:22:57 EST

We reported this as a feature request upstream to dnsdist developers in #10018; please see the issue for more details. It was then mentioned that they have already started working on it in #8918, but on the recursor (pdns-recursor) side, and it is marked for the rec-4.5.0 (pdns-recursor 4.5.0) milestone.

Once the features is merged in pdns-recusor, we need to do the following:

  • patch merged in pdns-recursor
  • test the patch to ensure integration with dnsdist
  • backport the patch from rec-4.5.0 to rec-4.4.2 given that it is unlikely we will upgrade to 4.5.0 just yet
  • update the Debian package to include the patch
  • write an integration test for it in knead-wikidough

Event Timeline

Change 736776 had a related patch set uploaded (by Ssingh; author: Ssingh):

[operations/puppet@production] dnsrecursor: add support for enabling EDNS padding

https://gerrit.wikimedia.org/r/736776

Change 736776 merged by Ssingh:

[operations/puppet@production] dnsrecursor: add support for enabling EDNS padding

https://gerrit.wikimedia.org/r/736776

Change 738251 had a related patch set uploaded (by Ssingh; author: Ssingh):

[operations/puppet@production] wikidough: enable support for EDNS padding

https://gerrit.wikimedia.org/r/738251

Change 738251 merged by Ssingh:

[operations/puppet@production] wikidough: enable support for EDNS padding

https://gerrit.wikimedia.org/r/738251

Responses are being padded to 468 bytes, as expected and per the RFC:

kdig @185.71.138.138 +tls-ca +tls-host=wikimedia-dns.org wikipedia.org
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 12358
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR
;; PADDING: 406 B

;; QUESTION SECTION:
;; wikipedia.org.      		IN	A

;; ANSWER SECTION:
wikipedia.org.      	581	IN	A	208.80.154.224

;; Received 468 B
;; Time 2021-11-11 10:04:42 EST
;; From 185.71.138.138@853(TCP) in 72.5 ms

And not being padded, in case we +nopadding:

kdig @185.71.138.138 +tls-ca +tls-host=wikimedia-dns.org wikipedia.org +nopadding
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 20192
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; wikipedia.org.      		IN	A

;; ANSWER SECTION:
wikipedia.org.      	526	IN	A	208.80.154.224

;; Received 47 B
;; Time 2021-11-11 10:05:37 EST
;; From 185.71.138.138@853(TCP) in 70.3 ms

However, there is a bug in dnsdist where it pads the responses incorrectly to 457 bytes instead of 468 bytes; we have reported it to them upstream at https://github.com/PowerDNS/pdns/issues/10884.

An example of an incorrectly padded response (and as we reported to dnsdist developers):

kdig @185.71.138.138 +tls-ca +tls-host=wikimedia-dns.org example.org
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 16682
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR
;; PADDING: 397 B

;; QUESTION SECTION:
;; example.org.        		IN	A

;; ANSWER SECTION:
example.org.        	86234	IN	A	93.184.216.34

;; Received 457 B
;; Time 2021-11-11 10:07:26 EST
;; From 185.71.138.138@853(TCP) in 73.4 ms

For more information on why this happens, please see the GitHub task above!