coredns: CoreDNS 1.2.5 returns large responses compared to upstream
Looks like CoreDNS is still not compressing responses in all cases.
DNS query for A record of domain app.datadoghq.com.
leads to a response of size 682. In comparison the upstream DNS server (1.1.1.1
in repro) is retuning a response of size 238.
Behavior is consistent for both proxy
and forward
.
Here is a minimal repro against CoreDNS 1.2.5. Last line of dig output shows MSG SIZE.
$ cat /tmp/Corefile
. {
forward . 1.1.1.1
}
$ docker run -d --name cdns-1.2.5 -p 5354:53/tcp -p 5354:53/udp -v /tmp/Corefile:/Corefile --entrypoint "/coredns" coredns/coredns:1.2.5 -conf /Corefile
cdns-1.2.5
9c7086b992390b26f87c5f2d55467a5f4e10bc6cf72c947aa7a5f390f06d9127
$ dig @127.0.0.1 -p 5354 A app.datadoghq.com.
; <<>> DiG 9.10.6 <<>> @127.0.0.1 -p 5354 A app.datadoghq.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64555
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;app.datadoghq.com. IN A
;; ANSWER SECTION:
app.datadoghq.com. 5 IN CNAME alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com.
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 54.208.252.45
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 107.23.209.202
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.197.177.186
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.207.51.240
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 52.70.197.48
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 54.165.203.141
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 54.172.103.190
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 54.174.194.200
;; Query time: 8 msec
;; SERVER: 127.0.0.1#5354(127.0.0.1)
;; WHEN: Fri Oct 26 16:48:43 PDT 2018
;; MSG SIZE rcvd: 682
$ dig @1.1.1.1 A app.datadoghq.com.
; <<>> DiG 9.10.6 <<>> @1.1.1.1 A app.datadoghq.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28842
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;app.datadoghq.com. IN A
;; ANSWER SECTION:
app.datadoghq.com. 5 IN CNAME alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com.
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 52.1.132.44
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 52.2.38.207
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 52.20.19.187
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.199.158.117
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.202.99.66
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.230.143.239
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.231.27.185
alb-web-shard1-1950469440.us-east-1.elb.amazonaws.com. 5 IN A 34.234.25.12
;; Query time: 50 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Fri Oct 26 16:48:53 PDT 2018
;; MSG SIZE rcvd: 238
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 15 (10 by maintainers)
IMO, it is working as expected : compression happen only if the size of the msg to send is larger than the size of the buffer the client can receive.
@usalim : what is your take ?