Hacker News Reader

Comment by beala | Hacker News Reader

I think the issue is that dnsmasq will happily forward requests that contain characters outside the ASCII subset, but the upstream resolver will silently drop them after correctly determining that they're invalid. So the special characters are a way of reliably triggering the silent drop upstream. This is required because it takes many attempts for the brute force attack to succeed.

View on HN

No. RFC 2181, section 11 states explicitly:

"Those [length] restrictions aside, any binary string whatever can be used as the label of any resource record.

Dnsmasq should (MUST in RFC 2119 language) forward requests -- it would be a bug not to. The upstream resolver shouldn't (MUST NOT in RFC 2119 language) silently drop them -- it would be a bug if they did.

Brute forcing transaction/port ID collisions to poison the cache is a long known flaw in the DNS protocol (it has been known since at least 1993) that led to the creation of DNSSEC.

No it didn't. The DNSSEC was a DoD/TIS project meant to make the DNS security model cohere with IPSEC, which at the time people believed would be the standard transport on the Internet. Then, when DNSSEC began to be taken more seriously as an operational security measure, it was because of the difficulty in authenticating additional data records in DNS responses --- the attacks Eugene Kashpureff used during his weird AlterNIC coup attempt. These aren't ID collision attacks at all.

It wasn't until Kaminsky combined transaction IDs with additional data poisoning in 2008 --- an entirely novel attack --- that BIND began randomizing and gave up on holding out for DNSSEC. You'll notice that since 2008 DNS cache poisoning has basically vanished as a real operational security concern. That's not because of DNSSEC.

It's unclear to me what "make the DNS security model cohere with IPSEC" means. DNSSEC was a direct response to the vulnerabilities identified by a number of folks and documented by Christoph Schuba (https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...). ISC was hired as a sub-contractor by TIS (I signed the contract for ISC) to implement DNSSEC in BIND specifically to address the transaction ID flood vulnerability.

I have around here somewhere the mail spool of the mailing list contemporaneous to the time and stand by my interpretation (the dns-security@tis.com list) --- I also worked "at TIS" (at Network Associates), writing the DNS security checks for NAI's security scanner (which included serverside components that actively exploited all these attacks) --- but that was a year or two after the contract, as I understand it. The COAST paper you're citing predates practical exploitation of QID prediction by 2 years, and the most significant DNS spoofing exploits of the time (the ones Kashpureff used) did not involve QID prediction.

I think the Kremlinology here is super interesting and I'm happy to keep digging with you, but again: DNS spoofing was a live issue for a couple months in 1995, when it was resolved by QID randomization in BIND (and then QID+port randomization in djbdns), and then a live issue again for about a month and a half in 2008, when it was finally resolved by QID+port randomization in BIND. DNSSEC had nothing at all to do with it.

Reply on news.ycombinator.com