3

We are working on a stablished network with a BIND9 server running (as well as many other services). I'm learning and trying to reorganize the old configuration files to comply with the present day (Many dead machines, unused names, reverse mapping and so on).

In the meantime, I'd love to follow best practices and secure the DNS with DNSSEC. While checking the configuration I stumbled across the fact that the TLD we use is not secured with DNSSEC.

My question: Is there any point (I bet it is) in securing our DNS with DNSSEC if upstairs (at super-domains) no one is doing so?

Our zone/domain space is under our university domain, directly under ve. space (Venezuela TLD). That is, something like example.university.ve. Neither ve or our university's DNS are secured.

If we should secure our subdomain anyway, I'd still like to know what problems would the insecure TLDs cause if any attacker comes by.

PS: I used tools like http://dnsviz.net/ and https://dnssec-debugger.verisignlabs.com/ to check on DNSSEC confs.

Mathias San Miguel
  • 33
  • 2

2 Answers2

5

The security of DNSSEC comes from having a cryptographically verified chain of delegation from some given data (like a set of A records) to a known and trusted public key (known as the "trust anchor"). For DNSSEC today, the normally used trust anchor is the root zone key. If your parent zone isn't signed, the chain from your zone to the root zone is broken, and DNSSEC's security guarantee fails totally. It doesn't matter if you sign your zone, because nobody else has a reason to trust the key you used to sign it with. Just as you can create a key and sign the zone with it, a bad guy can create a key and sign your (presumably slightly modified) data with that. Without a signed chain to a trust anchor, a third party has no way of knowing if they should trust your key or the bad guy's key.

Now, if you want some specific other people to be able to trust your signing, you can give them a key that they can use as a trust anchor for your domain. This is called "look-aside validation", and it hasn't been used much since the root zone got signed, but the standards and implementations are still there. If this would be interesting to you, go have a look at RFC 5074.

But in general, if your parent zone isn't signed, there is no point in you signing yours.

Community
  • 1
Calle Dybedahl
  • 2,083
  • 12
  • 17
  • 2
    DLV (look-aside validation) is now deprecated and should not be used any more as ISC is shutting down this service: https://dlv.isc.org/ – Patrick Mevzek Apr 11 '17 at 17:19
1

Your goal (of enabling DNSSEC) is laudable but

  • it is a lot of work to do DNSSEC correctly; even more because it is not oneshot, you need to maintain it (rotate keys, etc…) and monitor it
  • since you write starting with many other problems, I would advise first to clean everything and have a good zone running for some weeks/months before starting new projects, like enabling DNSSEC
  • like stated by Calle, and indeed .VE seems completely off any map regarding DNSSEC, without DNSSEC at all levels (and since now you can not use DLV anymore as I stated in my comment), it is worthless for you to add it on your zone

You should instead try to search why .VE does not do it: it could have decided not to do it, or decided to start it but still being in preliminary phases. You will then of course have the same problem with your registrar.

You could use for yourself and point them towards these resources that should provide ample data and documentation: http://www.internetsociety.org/deploy360/dnssec/

BTW, on https://stats.labs.apnic.net/dnssec I see that more than 10% of resolvers in Venezuela do validate DNSSEC records. This could help the .VE TLD to decide to activate DNSSEC.

Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42