Comment by belorn | Hacker News Reader

Comment by belorn | Hacker News Reader

Parent Full thread

The article/directive specifically called out DNS account passwords on DNS hosting providers. If they were using support tickets and manually implemented changes by hand then there would not be an account. With no account for a control panel you don't have any risk that the email and password gets dumped on pastebin. In the directive it even speaks about password managers, which again implies that the issue they are talking about are DNS control panels like the one at Route53, likely with reused password, and not bespoke systems.

For high priority domain names I would go so far and recommend against having a DNS control panel accounts on things like Route53. It has access control management but unless the department has the experience and skills it will likely end up with a single account that has full access with little oversight when something goes wrong. Those departments are likely better served going through a domain management company that handles all the security and manage who can request changes and how. If they have the experience and skills then managing it fully themselves can be a better option, but then what they really need is a registrar which allows for DNSSEC keys to be forwarded (with for example a cds record).

“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.

If they are using contractors that have DNS accounts with email and password as authentication, and who reuse that on other online websites which later get leaked, then that is major a failure in procurement when the bid was initially created.

> The point is that all infrastructure really should be managed with code

That I agree 100% with. If the agency itself has a IT department with experience and knowledge then the most optimal choice is that they do it themselves with either something like Terraform or their own physical hardware with authoritative DNS running on it. Agencies that is involved with either critical infrastructure, personal information, or state secrets should always have a security risk analyze done which describe what would happen if someone broke into DNS and where the vulnerabilities are. Sadly very few agencies does this.

Other agencies are likely better served by updating their procurement in respect to DNS management and make sure the requirements lists liability and high security. Make sure that rather than some cheap bulk registrar with a do-it-yourself control panel, where the registrar always have zero livability if the credentials are leaked, it is better to pay a more costly management company that manage the infrastructure with code.

> The article/directive specifically called out DNS account passwords on DNS hosting providers. If they were using support tickets and manually implemented changes by hand then there would not be an account.

I don't think it's difficult to imagine that, somewhere within the massive federal bureaucracy, there is a team that works on DNS record tickets filed by other parts of the bureaucracy, and logs into a web console with a DNS hosting provider in order to fulfill those tickets.

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.

Reply on news.ycombinator.com