> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?= <c...@stdlib.net>
> Economics also include costs. The operational cost of deploying DNSSEC > validation on resolvers remains high - there are still frequent key > rotation and signing errors that cause various DNS subtrees to be > unresolvable. On what do you base your claims about the fatal costs of DNSSEC validation? I claim relevant knowledge and experience, not just from code I wrote a few years ago to reduce the costs of DNSSEC on very large resolvers, but from signing my own domains and enabling validation on all of the resolvers that I control. My domains and resolvers are insignificant, but I hope I would have noticed any fatal costs. Are you aware that Comcast's resolvers have been validating for some time? I think Google is also validating based on a "Webmaster, your web page is not available to your spider" messages after a configuration error in my signing machinery, but am not sure. Does that conflict with your claims about the fatal costs of validating? Yes, I've noticed that Google is still not signing. Maybe the continuing hijackings of their ccTLD domains will move them. > If an attacker can cause the domain to be unresolvable, that seems > like a weakness. True, but the right question is not "Does DNSSEC add vulnerabilities?" but "Overall, is DNS more or less secure with DNSSEC?" or "Among all of the things I can do, what will improve the security of my users and the Internet in general?" Defenders who care about the security of their systems and the Internet in general don't pick and choose among weaknesses based only on what is easiest, what can be punted to others, or what contributes to their reputations. They don't do as Steve Gibson did and harp on the bogus catastrophy of Windows XP raw sockets to enhance his reputation and sell his services. > Kaminsky wasn't the discoverer of the "Kaminsky's bug" either, it was > long known, yet here you credit him. Not that I mean to deny credit to > Kaminsky, he did a good job of publicising the vulnerability. Just as > Haya has done here. I suspect Kaminsky got the credit because he had been contributing to the field for years. But who cares who got there first? Every request I see for credit is recorded in my private accounting as a debit against the credibility of the person demanding credit, because credit demands suggest interests which suggest biases and so inaccuracy. Yes, I've heard of Kaminsky's business interests, and so I don't take his announcements at face value. You should also discount my credibility based on my pecunary or other interests. Where you can't determine my interests, act on your best guess. > Back before Kaminsky made the need for port-randominsation undeniable > with an actual working PoC, this sounds like the ISC/Bind response to > port randomisation attacks. Other implementors and operators made a > better judgement avoided the problem entirely, taking the cautious > path. 5 years later, are you really saying we should ignore another > attack vector? Who besides you and Haya Shulman has said anything about not randomizing ports? What port randomization improvements do you think are needed in current releases of any major DNS implementation? Where port randomization problems exist such as in junk CPE that won't get fixed before I retire, what contributes most to solutions, selling $29.95/#24.95/£19.95 academic papers or turning on DNSSEC? The issue for me is one of relative priorities. Among all Internet security issues that I might touch, which should get my attention and effort? By remaining silent about emphasising port randomization over DNSSEC (or using distant instead of nearby validating resolvers) would I help or harm? > The impact even with DNSSEC fully enabled seems concerning enough to > warrant attention. Let's agree that ports ought to be as random as TCP ISNs, improve port randomness where each of us can, and stop implying that anyone thinks or says otherwise. Let's also stop the "DNSSEC is a problem" stuff. Finally let's consider how you are helping. Is there anything you can do to improve port randomization? If you are committer in any open or proprietary source trees, will you make any needed port randomization fixes? Have you deployed DNSSEC? What about BCP 38, since cache poisoning is likely to depend on BCP 38 violations? Vernon Schryver v...@rhyolite.com
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs