[GH-ISSUE #2941] preserve_rdata fuzzer: Gracefully handle inputs with compressed names in the wrong places #1098

New issue

Closed

opened 2026-03-16 01:36:10 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 01:36:10 +03:00

Owner

Originally created by @divergentdave on GitHub (Apr 18, 2025).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2941

Fuzzer input may produce records that use compressed names inside RDATA for record types that are not allowed to use compressed names. Hickory DNS can currently handle such cases, decompressing the names so long as the record type is supported, and I think we should keep it that way. Thus, the fuzzer will need some additional logic for each record type Hickory DNS supports that contains embedded names. For the well-known record types, we already decompress names in the original fuzzer input, and decompress names in the output of Hickory DNS's decoding and re-encoding, to account for allowable differences in representation. For these remaining record types, where name compression is not allowed by the RFCs, we need to decompress names in the fuzzer input, and compare that directly to the Hickory DNS re-encoding output.

I plan to put this off for now, until after fixing some other issues revealed by this fuzzer (i.e. #2925 and #2934).

Originally created by @divergentdave on GitHub (Apr 18, 2025). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2941 Fuzzer input may produce records that use compressed names inside RDATA for record types that are not allowed to use compressed names. Hickory DNS can currently handle such cases, decompressing the names so long as the record type is supported, and I think we should keep it that way. Thus, the fuzzer will need some additional logic for each record type Hickory DNS supports that contains embedded names. For the well-known record types, we already decompress names in the original fuzzer input, and decompress names in the output of Hickory DNS's decoding and re-encoding, to account for allowable differences in representation. For these remaining record types, where name compression is not allowed by the RFCs, we need to decompress names in the fuzzer input, and compare that directly to the Hickory DNS re-encoding output. I plan to put this off for now, until after fixing some other issues revealed by this fuzzer (i.e. #2925 and #2934).

kerem closed this issue

2026-03-16 01:36:15 +03:00

kerem commented

2026-03-16 01:36:21 +03:00

Author

Owner

@divergentdave commented on GitHub (Jun 11, 2025):

An easier way to handle messages with compressed names in the wrong places would be to reject the fuzzer input, and exit with success before doing any further decoding or comparison. This will still require the fuzzer to independently parse RDATA for each record type that Hickory DNS supports, but we'd just have to check each name label, not do any re-encoding.

@divergentdave commented on GitHub (Jun 11, 2025): An easier way to handle messages with compressed names in the wrong places would be to reject the fuzzer input, and exit with success before doing any further decoding or comparison. This will still require the fuzzer to independently parse RDATA for each record type that Hickory DNS supports, but we'd just have to check each name label, not do any re-encoding.