domain::zonefile::inplace::Zonefile adds two extra bytes to the public key of a DNSKEY record
jrb0001 opened this issue · comments
I previously used version 0.7.2 to parse the root zone and it worked fine. After updating to 0.8.0 and migrating my code to use domain::zonefile::inplace::Zonefile, I get two extra bytes at the end of the KSK public key. I don't know DNSSEC well enough to know if the key is still valid like this, but I would expect the library to give me the original data back.
Small repro:
/*
[dependencies]
domain = { version = "0.8", features = ["zonefile"] }
*/
use domain::zonefile::inplace::{Entry, ScannedRecordData, Zonefile};
const ROOT_ZONE: &str = "
. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2023060200 1800 900 604800 86400
. 172800 IN DNSKEY 256 3 8 AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDgpJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g+NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtkepVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9porIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabE=
. 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
";
fn main() {
let mut zonefile = Zonefile::new();
zonefile.extend_from_slice(ROOT_ZONE.as_bytes());
for entry in zonefile {
if let Entry::Record(record) = entry.unwrap() {
println!("{}", record);
}
}
}Gives the following output:
.. 86400 IN SOA a.root-servers.net.. nstld.verisign-grs.com.. 2023060200 1800 900 604800 86400
.. 172800 IN DNSKEY 256 3 RSASHA256 AwEAAbF1LAxEQPtClEQno48k6u7JjCOfVfwdENOxQUrX0JbpN5DnKGMAKIfdiWa5oDeKQ3OoQ58yCC8vjtaaGFDgpJxoLwqzhBYHPGFgins5HIERcCQPGAJKWu/ku4XLh+Fu7UyBubDCelxKTbnj26EwbochltRqGIE8hbwSXEzRNo4g+NXkaRMq2FFbaBtEE82yTmZUgFRYAFUvfGTPWblyZGtkepVuHyNb0w/u24dpsz+uyCZZR04cHfRrWOKvqD3lDOwC4+sqd6f7F841R0N2tqSh/WDUZzWdvPBaBOz0FWFLb9porIeZ3Jm08tAMHa+3SGRXfK4RAmxVCmIQQypGabFG
.. 172800 IN DNSKEY 257 3 RSASHA256 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bV7
Also it looks like the new version parses . into a Dname with two empty labels.
Thank you for the report! This is definitely an issue – looks a bit like the padding of the Base 64 data isn’t handled correctly. We have a test case for this data but stupidly, it doesn’t include any padding.