New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Client fails to verify records with uppercased names #27
Comments
Thanks for the testcase and the description! I will take a look later tonight and see about fixing it. |
Nice work on the diagnosis. I knew that I had a problem here for other reasons, but you definitely found it. I'm adding your test case to the code for now, as an integration test. I knew I had a query response issue to fix on improperly converting the case of this. I will try to push a fix tonight. Just adding some other test cases to validate cases. |
Thanks and looking forward to the fix! I found this when writing my recursive resolver project. :) |
Ok, I just pushed a patch to the 0.7.1_patch branch. Though, I have been having trouble with the UDP tests passing consistently, the TCP ones do regularly. I'll have to look into why the UDP ones fail inconsistently. I will try and push a release to creates.io tomorrow for this. It also fixes an inconsistency issue with queries where the case of the responses was being changed. |
btw, the integration tests are all marked with |
Thanks for the fix! Will try it a bit later. :) |
fixes #27: remove implicit case conversion of labels
OK, have been fiddling with this over the last 2 days and I have the following observations:
let mut lower_name = Vec::<String>::new();
for i in 0..(name.num_labels() as usize) {
// lower_name.push(name[i].clone());
lower_name.push(name[i].to_lowercase());
}
assert!(Name::with_labels(lower_name).emit_as_canonical(&mut encoder, true).is_ok()); Sidenote: Just a suggestion, maybe we should re-implement |
Thanks for all the hard work on this. I really appreciate it. Are you working off a release or HEAD? I'd like to start applying these changes to HEAD.
Do you want to submit separate patches for these against HEAD? Otherwise I can look at fixing them. Sidenote: I definitely considered this, but I got caught in an internal debate. Do we want to also compare regardless of case, or do we want people to be explicit? The reason that I went the direction I did is that I decided we at least needed both. We can invert that decision though, and make Eq + Hash case insensitive, and then offer a case_sensitive compare function. |
Sure, I will send my fixes to the 3 issues as pull request a bit later. :) Regarding sidenote: I am actually biased as my project needs case insensitive comparison and hashing everywhere. :) Anyways I just did a bit of research and found RFC 4343 which explicitly states name comparison should be case-insensitive. I agree that maybe in some cases we need to do case-sensitive comparison, but it is much rarer and it will be more convenient to implement |
I'll work on fixing the name issue, if you want to send the other fixes, that would be a great help. |
Oh I forgot to post about the UDP issue. If I remember correctly, the offending response is more than 1700 bytes so 1500 in our setting is not enough. Although the real issue is that it seems Google's server hardcoded 512 bytes in their EDNS header, so it will never send us the correct response and we have to revert to TCP anyways. |
Just submitted patch for the TCP issue. Not quite sure where is the correct place for the |
Here is a test case to help checking the verification issue: #[test]
fn test_dnssec_rollernet_td_tcp_mixed_case() {
use ::tcp::TcpClientConnection;
use ::client::Client;
use ::rr::Name;
use ::logger::TrustDnsLogger;
use log::LogLevel;
TrustDnsLogger::enable_logging(LogLevel::Debug);
let c = Client::new(TcpClientConnection::new("8.8.8.8:53".parse().unwrap()).unwrap());
c.secure_query(
&Name::parse("RollErnet.Us.", None).unwrap(),
DNSClass::IN,
RecordType::DS,
).unwrap();
} |
@SAPikachu I added that test, and went through and adjusted all cases. I added the case-insensitive cmp, eq, and hash. I got the test_dnssec_rollernet_td_tcp, this adjusts the case in the record labels in the RRSIG validation, but it doesn't adjust the signer_name. The spec seems to say that both should be lowercased, but when I do both test_dnssec_rollernet_td_tcp fails to validate. neither change gets test_dnssec_rollernet_td_tcp_mixed_case passing. To be clear, what is in the 0.7.3_name_patch has test_dnssec_rollernet_td_tcp passing, but not test_dnssec_rollernet_td_tcp_mixed_case |
OK, I tested and found that SOA record of |
And this is why case-insensitivity is dumb :) I'll patch this up tonight. Thanks for doing all the research! |
Ok, I think this recent patch fixes it up... I pulled your TCP patch in to make the connections more reliable. Good catch on that fix! I'm going to push a new version and then merge this back to master. The serialization code could definitely be cleaned up at this point, it's a little ugly. |
Thanks! I just submitted a patch to fix |
Is this something you want in the 0.7.x release? Otherwise I'll just leave merged on master and then include it in the next release.
|
It doesn't matter for me since I can use master, so you decide. :) |
Test case:
This fails with
No DNSKEY proof available
error while validating the returned NSEC record, but according to http://dnsviz.net/d/rollernet.us/dnssec/ , the server returns correct RRSIG. From what I can tell, this server returns uppercased names in the record, but all names are converted to lowercase on deserialization, which breaks verification.The text was updated successfully, but these errors were encountered: