anoncontractor

I don’t work for AWS, but I’ve talked to people that work on Route53. Amazon just isn’t willing to support it, none of their large customers care about it enough it seems like. Plus DNSSEC has all sorts of issues, some of which people in the thread have mentioned. Actually, tptacek has a blog post that summarizes a lot of what’s wrong with DNSSEC iirc.

“If they were using support tickets and manually implemented changes by hand then there would not be an account.”

Your contracting team may not have a DNS account, but the contractor that deals with DNS changes certainly does.

The point is that all infrastructure really should be managed with code. If you managed DNS from Terraform you’d notice that your production DNS system was in conflict from what your code said it should be the next time a terraform plan/apply was run (which is happening all the time from dev or maybe CI). Without it you could go months or years without noticing a changed entry on a little used, but critical system. From what I remember this attack was ongoing for a couple years before it was noticed.

Yes, this is pretty close to how this agency does things. Your contracting team files a support request for a record change and a manager from within the agency approves. The contractor that owns DNS changes then goes and does it.

This makes all sorts of other things bad, like generating TLS certs with automation, as typically a validation for cert generation will be done via a DNS entry to prove ownership. But that requires a support ticket, so no automation will work here.

For sure, you can totally make something like this happen, but again that means writing and securing a bespoke system. If you’re a team managing your AWS infrastructure with Terraform, it sucks to have to write a totally different system (and all the secrets management that goes along with it).

Additionally, for a government agency you could have dozens of contractor teams, and you need a method of securing access for all of them. It’d be much easier to just use Route53 and delegated subdomains, as all teams are largely deployed and managing infra (with MFA) there.

But it’s not allowed, because DNSSEC.

As someone who has recently dealt with a major government agency, the requirement of DNSSEC means that agencies can’t use Route53 as it doesn’t support DNSSEC. This makes it much less likely that an agency will use something like Terraform for managing DNS, which would help in making sure all records are validated and easily auditable. Instead, many DNS records are managed by hand or with bespoke systems. The best case is that it’s managed by maybe Akamai, but records are still updated via support tickets and implemented by hand (as akamai’s Terraform support is pretty bad).

So it’s relevent to mention DNSSEC because it’s spoken of within the government as a method of securing DNS, but in reality it makes things worse. It doesn’t protect against attacks like these and the end result is you are forced to use a crappy system that makes you even more vulnerable to these sorts of attacks. It’s the worst of all worlds.

(Also, I was on the call they held for CIOs and tech leaders of all agencies, and it was astonishing how many of the questions in their chat made it obvious that many of the entrenched players didn’t even understand how this attack worked.)