Repository navigation
Packets recorded in data files may not reflect the packets actually received in wire format #1554
Description
I tried rerecording t/Test-zone09.data and I noticed the packets for the MIXED-CASE-RDATA-2 scenario are not recorded faithfully.
Expected are two MX records with the same preference value and hostnames only differing in case, like so:
$ dig +noedns +nord @fda1:b2:c3:0:127:19:9:31 MX mixed-case-rdata-2.zone09.xa
; <<>> DiG 9.18.39-0ubuntu0.22.04.6-Ubuntu <<>> +noedns +nord @fda1:b2:c3:0:127:19:9:31 MX mixed-case-rdata-2.zone09.xa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23328
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mixed-case-rdata-2.zone09.xa. IN MX
;; ANSWER SECTION:
mixed-case-rdata-2.zone09.xa. 600 IN MX 20 mail2.mixed-case-rdata-2.zone09.xa.
mixed-case-rdata-2.zone09.xa. 600 IN MX 20 MAIL2.MIXED-CASE-RDATA-2.ZONE09.XA.
;; Query time: 0 msec
;; SERVER: fda1:b2:c3:0:127:19:9:31#53(fda1:b2:c3:0:127:19:9:31) (UDP)
;; WHEN: Fri Sep 25 08:45:32 CEST 2026
;; MSG SIZE rcvd: 202
But what actually gets recorded in the data files is the following.
$ ./util/data2dig t/Test-zone09.data | less
[...]
;; Query to ns1.arpa-email-domain.zone09.arpa (fda1:b2:c3:0:127:19:9:31) over UDP
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR
;; flags: ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mixed-case-rdata-2.zone09.xa. IN MX
;; MSG SIZE sent: 46
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0
;; flags: qr aa ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; mixed-case-rdata-2.zone09.xa. IN MX
;; ANSWER SECTION:
mixed-case-rdata-2.zone09.xa. 600 IN MX 20 mail2.mixed-case-rdata-2.zone09.xa.
mixed-case-rdata-2.zone09.xa. 600 IN MX 20 mail2.mixed-case-rdata-2.zone09.xa.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 0 msec
;; SERVER: fda1:b2:c3:0:127:19:9:31
;; WHEN: Fri Sep 25 08:38:48 2026
;; MSG SIZE rcvd: 84
This bug was discovered while debugging why a unit test passed while it shouldn’t have (see #1543 (comment)).
This issue is rather serious because it can cast doubts on the correctness of unit tests using recorded data if that recorded data cannot be trusted to be faithful. The likely culprit is that some round-trip conversion is done from the original wire format to some internal format, back to wire format, in a way that is lossy.
Activity
matsduf commentedon Sep 25, 2026
Is saving to cache possibly being done after the test case down-cases the data?