[GH-ISSUE #1677] Response parsing is broken for `SvcParamKey::Unknown` #734

New issue

Closed

opened 2026-03-16 00:03:26 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 00:03:26 +03:00

Owner

Originally created by @jeff-hiner on GitHub (Apr 7, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1677

Describe the bug
Response parsing broken for SvcParamKey::Unknown

The SvcParamValue is 35 bytes long, indicated by the len at the beginning of the buffer. But by the time Unknown::read(&mut decoder) is invoked the length has already been read from the stream, so the decoder isn't able to read the number of bytes.

To Reproduce

let name = "pancake.cdn-apple.com.akadns.net.";
let resolver =
    TokioAsyncResolver::tokio(ResolverConfig::cloudflare(), ResolverOpts::default()).unwrap();
let result = resolver
    .lookup(name, RecordType::HTTPS, Default::default())
    .await;

eprintln!("result: {:?}", result);

Expected behavior
Two records show up directly via dig, a CNAME and an HTTPS record. Those records should also show up here. Instead, the resolver hangs because all responses are dropped as unparseable.

System:

OS: repros on Debian and on MacOS
Architecture: x86_64
Version 0.21.2 tag
rustc version: 1.60

Version:
Crate: proto
Version: 0.21.2 tag (latest main)

Additional context

Originally created by @jeff-hiner on GitHub (Apr 7, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1677 **Describe the bug** Response parsing broken for `SvcParamKey::Unknown` The SvcParamValue is 35 bytes long, indicated by the len at the beginning of the buffer. But by the time `Unknown::read(&mut decoder)` is invoked the length has already been read from the stream, so the decoder isn't able to read the number of bytes. **To Reproduce** ``` let name = "pancake.cdn-apple.com.akadns.net."; let resolver = TokioAsyncResolver::tokio(ResolverConfig::cloudflare(), ResolverOpts::default()).unwrap(); let result = resolver .lookup(name, RecordType::HTTPS, Default::default()) .await; eprintln!("result: {:?}", result); ``` **Expected behavior** Two records show up directly via `dig`, a CNAME and an HTTPS record. Those records should also show up here. Instead, the resolver hangs because all responses are dropped as unparseable. **System:** - OS: repros on Debian and on MacOS - Architecture: x86_64 - Version 0.21.2 tag - rustc version: 1.60 **Version:** Crate: proto Version: 0.21.2 tag (latest `main`) **Additional context**