I work in a field where we deploy software as a service for customers in various regulated fields, and DNSSEC is something that auditors look for as a checkbox to check that DNS is secured.
So far we've let AWS Route53 deal with the whole DNSSEC thing, but it has made moving hosted zones from one AWS account to another more difficult and more troublesome than it should have been, and making sure that DNSSEC is setup on all of them is frustrating and annoying.
Thankfully we haven't encountered any issues with DNSSEC signing causing downtime, but I expect it will happen when someone misconfigures a DNSSEC record somewhere and now we gotta wait for the caches to empty/clear.
Which audit requires DNSSEC? SOC2 certainly doesn't. ISO doesn't. HITRUST doesn't. PCI doesn't. FedRAMP might (we'll see how much longer that remains the case).
Most firms aren't DNSSEC-signed, most especially those with well-resourced security teams, the kind that collect all the available audit certifications because they have teams dedicated to doing that.
It's a requirement from some of our customers in the financial industry, as well as gov't. It's something various security firms have asked for, and it's a checkbox we will continue to just check. No matter how useless I think it is.
That's fine, I understand. I'm not telling you how to live your life. All I'll say is: there are SOC2 firms that will also tell you to turn DNSSEC on. You can tell them to go fuck themselves, and you'll be just fine. I don't know if that's the case with your NY-FI customers (none of the major investment banks are signed, nor are any of the exchanges, nor are the largest hedge funds and prop traders, but that's neither here nor there); only you know how to handle them.
I'm just here to establish that the mainstream security audits definitely don't require DNSSEC. :)
My experience with these types of audits and security questionnaires is that there are usually a lot of items that aren't actually important either in general, or for your specific company/product. And often if you can provide a compelling argument why you don't actually need something, the customer will usually be ok with it. But the more of those there are, the longer it takes to close the deal, or finish the audit, and the more resources you have to spend on it.
This is why 'cookie cutter audits' are fairly useless, a standard should establish a framework but not result in endless bickering about stuff that isn't even applicable.
There is a huge difference here when it comes to who pays. If a customer of the company pays for the audit you can expect a whole pile of trouble because the auditor wants to show that they've delivered value, whereas if the company being audited pays for it then it tends to go the other way. Ideally the audit would be exactly the same no matter who pays for the audit and it should be customized to the company (and market).
The finance systems I’m familiar with generally don’t rely on DNS for security and, more commonly, don’t rely on it at all. For systems operating over the open Internet, the most common security mechanisms involve pre-shared key pairs. For systems not on Internet, IP (v4) addresses are generally used directly.
I’m actually generally disappointed that TLS in the context of web browsers essentially only uses the CA system for identification and security. It’s wrong at both ends of the spectrum. There are systems where manual key distribution would be fine, and avoiding the CAs as a weak point would be beneficial. And there are systems where the CA system flat out does not work (e.g. anything where the servers are not connected to the Internet and do not even have every-few-days Internet access). Neither of these use cases are handled well by web browsers. (DNSSEC doesn’t help either, of course.)
This is why I said “do not even have every-few-days Internet access”. Without some kind of recurring connectivity, certificate renewals are impossible. (The client could, in theory, help, but that’s not a thing right now.)
Systems like this are all over. Almost every IoT device is an example. More seriously, networking hardware is in this category. You can’t make connectivity to networking hardware depend on a working network with Internet access to obtain certificates without introducing a circular dependency and the possibility of making it very hard to recover from downtime.
As a result, security of network control planes is often abysmal.
I'm not clear here if "Internet access" means incoming access, outgoing access, or neither.
To be clear, the solution above requires no incoming access. Its 100% client, there's no server access. (Client to the DNS Api, client to ACME.
If the device does not have client access to anything then the certificate can be obtained from another device. You would then need some mechanism to put the certificate on the device.
I agree that IoT devices are problematic, they either need client access to the Internet (which most don't get) or they need to run a "server" of some kind to receive the certificate updates. If you're lucky this could be automated.
I have found it relatively easy to just run a local CA for my isolated network. I didn't find it too difficult to setup. I run around 600 servers and about 20x that in IOT devices.
And how did you provision any of this? Did you take each device, connect to it while on that same network in a completely unauthenticated manner, and provision certificates? Can you send links to webpages on these devices to ordinary browsers that aren’t provisioned with the certificates? Would someone who doesn’t fully trust you and your infrastructure be willing to install your certificate?
> You can’t make connectivity to networking hardware depend on a working network with Internet access to obtain certificates without introducing a circular dependency and the possibility of making it very hard to recover from downtime.
> C) provision certificates for this address using the DNS-Challenge approach rather than the HTTP-challenge approach.
The other "bonus" is that due to CT it leaks the internal name to basically everyone on the internet. It may or may not be a problem but definitely something to be aware of.
>> (e.g. anything where the servers are not connected to the Internet and do not even have every-few-days Internet access
It is possible to add your own root certificate to clients on the LAN. so the equivalent of hand-distributed keys. Granted, this leads to unwelcome other problems (you can't limit your root to your local domain) so it's not often done, but it is possible.
Personally I prefer the DNS-challenge approach I described in a sibling comment.
NameConstraints used to break in Safari: if you didn't set them mandatory, the constraints would be ignored and you could sign anything; if you set them mandatory, the certificate wouldn't validate. But it looks like support was added in 10.13.3, circa 2018, so probably good to go.
Might break some things, and I'm not aware of any mainstream uses, but obviously it'd be really handy if it's usable.
This is actually something important: auditors are all over the place and the 'checkbox types' tend to be insistent on all kinds of busywork that the standard they are auditing against doesn't require at all. As the company being audited you are definitely in a position to push back (but maybe not with that particular language).
If you know the standard you are audited against as well or better than your auditor you're in a good position to spot such deviations and avoid a bunch of unnecessary (and sometimes conflicting) 'requirements'. The less competent auditors might not like this but they're probably not going to challenge serious pushback and if they do you're free to contact their employers and ask for someone more qualified.
There's a historic DNSSEC requirement from the USG, which is actually a big chunk of the reason anyone invested in DNSSEC in the early 201x's. But then it got rescinded, but then it stuck in some of the OMB documents, and it's become a weird political football (in the fleeting moments anybody thinks about it) so we're in a weird limbo where every once in awhile teams like Slack turn it on to close some FedGov business and fall off the entire Internet for a half day when DNSSEC eats them.
And from there, it’s more recently worked its way into the minimum mandatory set of requirements in the StateRAMP baseline and the state specific variations such as TX-RAMP and AZ-RAMP.
We’re working with customers who will be subject to DNSSEC requirements due to business with state universities, and we will be trying to make a case with the sponsoring agencies to avoid deploying on their domains.
The Australian government’s offical cybersecurity guidelines recommend - but do not require - Australian government agencies to implement DNSSEC, “where possible” and especially on their “principal domains”. In a competitive procurement, if another vendor says “you want DNSSEC? No problem!”, while you are saying “we don’t support that” or trying to argue against the recommendation - that is unlikely to help in winning the deal. If your product is miles ahead of the competition, it might not matter; if it is close, this might be the thing that loses it.
It's funny how the USG might be conflicted with both an interest in DNSSEC adoption, and an interest in preventing its adoption.
Less than a year ago I was having DNS problems reaching a subnet in the spaceforce.mil domain (via AFRC Desktop Anywhere). After some troubleshooting, I determined that the DNS server for their subnet was not configured for DNSSEC and my client was configured to refuse unauthenticated resolvers. Everything worked fine once I turned off DNSSEC locally.
DNSSEC can prevent spoofing via MITM, which is something that lots of governments do, so I can see why they might not want everyone to adopt it.
On the other hand, DNSSEC can help to secure network communication, so I can see why they might want to adopt it.
> DNSSEC can prevent spoofing via MITM, which is something that lots of governments do, so I can see why they might not want everyone to adopt it.
Only if you're NOT using HTTPS, right? In which case your traffic is already trivially spoofable, so you're not really gaining anything else by using DNSSEC there.
Does Route53 let you manage the DNSKEY RRset (so you can add a DNSKEY to the set yourself) or do they have some sort of facade you have to interact with instead?
That's an answer to a different question. I asked if they let you put a DNSKEY RR in the RRset they serve. (To be clear: I'm not asking if they will import private keys and sign with them or anything like that, just if they'll let you place an additional DNSKEY in the RRset they serve.)
I had to add a DS record to a Route53 zone just the other day, and when I did, I didn't see a DNSKEY option in the list of records. Don't count on that 100% because I wasn't looking for it, but I definitely don't recall seeing it.
So far we've let AWS Route53 deal with the whole DNSSEC thing, but it has made moving hosted zones from one AWS account to another more difficult and more troublesome than it should have been, and making sure that DNSSEC is setup on all of them is frustrating and annoying.
Thankfully we haven't encountered any issues with DNSSEC signing causing downtime, but I expect it will happen when someone misconfigures a DNSSEC record somewhere and now we gotta wait for the caches to empty/clear.