Bug: ECS (EDNS) inaccurately reported when served from cache (related to #3978)

[gspannu]

I think I have identified a bug in ECS(EDNS) implementation ... related #3978

Running the latest edge build...

Try these following commands
dig o-o.myaddr.google.com txt +subnet=4.5.6.7/24 @AGHServerIP
Response (which is correct)

;; ANSWER SECTION:
o-o.myaddr.google.com.	55	IN	TXT	"172.217.47.130"
o-o.myaddr.google.com.	55	IN	TXT	"edns0-client-subnet 4.5.6.0/24"

---

Now try the same command with different ECS subnet data

dig o-o.myaddr.google.com txt +subnet=1.2.3.4/24 @AGHServerIP
Response (which seems to be incorrect)

;; ANSWER SECTION:
o-o.myaddr.google.com.	27	IN	TXT	"172.217.47.130"
o-o.myaddr.google.com.	27	IN	TXT	"edns0-client-subnet 4.5.6.0/24"

Observation

I had sent different subnet values to AGH (4.5.6.7/24 and 1.2.3.4/24), but if the response is served from cache, then the previous (cached) ECS data is reported by AGH in subsequent queries.

---

As shown by AGH Query log...

First request

Second request (responded by cache)

[agneevX]

Does this persist after the TTL of the records expire?

[Birbber]

@gspannu Sorry for the long silence! Is this issue still relevant in the latest release?

[gspannu]

@agneevX @Birbber

The bug still persists.

The incorrect ECS data (always responds with cached) is reported in subsequent requests, regardless of whether the subsequent request is executed within TTL or post TTL.

Simple example to help you test...
Send this command to a AGH
dig o-o.myaddr.google.com txt +subnet=4.5.6.7/24 @AGHServerIP

Now send this command (with changed subnet)
dig o-o.myaddr.google.com txt +subnet=1.2.3.4/24 @AGHServerIP

Th response is always the same a the 1st request, subsequent responses do not honour the subnet details, AGH responds with cached data.

[agneevX]

I was unable to reproduce this.

docker run --rm -p 7000:53/udp hezhijie0327/dnsproxy:latest -u 8.8.8.8:53 --cache --cache-optimistic

~> dig TXT o-o.myaddr.l.google.com @localhost -p 7000 +subnet="1.1.1.0/24"

; <<>> DiG 9.16.1-Ubuntu <<>> TXT o-o.myaddr.l.google.com @localhost -p 7000 +subnet=1.1.1.0/24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33587
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.myaddr.l.google.com.	IN	TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 60	IN	TXT	"172.217.34.197"
o-o.myaddr.l.google.com. 60	IN	TXT	"edns0-client-subnet 1.1.1.0/24"

;; Query time: 131 msec
;; SERVER: 127.0.0.1#7000(127.0.0.1)
;; WHEN: Thu Aug 18 12:04:00 IST 2022
;; MSG SIZE  rcvd: 122

After 60 secs:

~> dig TXT o-o.myaddr.l.google.com @localhost -p 7000 +subnet="8.8.8.0/24"

; <<>> DiG 9.16.1-Ubuntu <<>> TXT o-o.myaddr.l.google.com @localhost -p 7000 +subnet=8.8.8.0/24
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51204
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;o-o.myaddr.l.google.com.	IN	TXT

;; ANSWER SECTION:
o-o.myaddr.l.google.com. 54	IN	TXT	"2404:6800:4000:1001::102"
o-o.myaddr.l.google.com. 54	IN	TXT	"edns0-client-subnet 8.8.8.0/24"

;; Query time: 0 msec
;; SERVER: 127.0.0.1#7000(127.0.0.1)
;; WHEN: Thu Aug 18 12:05:06 IST 2022
;; MSG SIZE  rcvd: 132

[ainar-g]

No response for over a year; closing.