With EDNS enabled, drill’s additional section count display ignores the OPT pseudo-RR

[marc-vanderwal]

When a DNS server responds with an EDNS-enabled message (containing an OPT pseudo-RR in its additional section), LDNS and drill show an ADDITIONAL: count that is one less than the actual size of the additional section.

For example, with this query, made against a public DNSSEC-validating resolver, EDNS is used, so the second line of the output should display ADDITIONAL: 1 instead of 0, as seen here:

$ drill -w answer.hex -D @ns1.nic.fr afnic.fr
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 17683
;; flags: qr aa rd ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; afnic.fr.    IN      A

;; ANSWER SECTION:
afnic.fr.       600     IN      A       51.178.83.21
afnic.fr.       600     IN      RRSIG   A 13 2 600 20240930021211 20240831080819 14683 afnic.fr. kfKSFDVwefYtcEbDx7c1LtacO5tIcQN5wNOtgc7Y384YmwJiopqqbeD+ocz7ipmYvzhaW6a6qla2Yd+k/YgTrw==

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; EDNS: version 0; flags: do ; udp: 1432
;; SERVER: 192.134.4.1
;; WHEN: Tue Sep  3 08:35:13 2024
;; MSG SIZE  rcvd: 157

The hex dump of the response shows indeed that the raw packet has an ARCOUNT of 1 in the header (bytes 10-11).

$ cat answer.hex
; 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19
;-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
 45 13 85 00 00 01 00 02 00 00 00 01 05 61 66 6e 69 63 02 66    ;          1-  20
 72 00 00 01 00 01 c0 0c 00 01 00 01 00 00 02 58 00 04 33 b2    ;         21-  40
 53 15 c0 0c 00 2e 00 01 00 00 02 58 00 5c 00 01 0d 02 00 00    ;         41-  60
 02 58 66 fa 08 fb 66 d2 cf 73 39 5b 05 61 66 6e 69 63 02 66    ;         61-  80
 72 00 91 f2 92 14 35 70 79 f6 2d 70 46 c3 c7 b7 35 2e d6 9c    ;         81- 100
 3b 9b 48 71 03 79 c0 d3 ad 81 ce d8 df ce 18 9b 02 62 a2 9a    ;        101- 120
 aa 6d e0 fe a1 cc fb 8a 99 98 bf 38 5a 5b a6 ba aa 56 b6 61    ;        121- 140
 df a4 fd 88 13 af 00 00 29 05 98 00 00 80 00 00 00

This behavior can be pretty misleading because one might expect that drill’s first two lines faithfully show what’s in the packet’s header. It’s also inconsistent with dig and kdig, which do show an additional section count of 1 in their respective outputs (try dig +dnssec +nocrypto @ns1.nic.fr afnic.fr and kdig +dnssec +nocrypto @ns1.nic.fr afnic.fr respectively).