2

I know that the overall purpose of DNSsec is to prevent spoofing your DNS record. But what are some of the actual processes/routines that are used that DNSsec actively prevents?

nix
  • 145
  • 4

2 Answers2

1

A good introduction to DNS related threats are given in RFC3833. Basically DNSSEC is one way among others to be sure that the server you are connecting is really legitimate. However, it is just one layer of security and not satisfactory on its own: it does not prevent re-routing your traffic to somewhere else or interpret the packets it they are not encrypted.

The main disadvantage of DNS nowadays is that it must be supported on both ends. It does not make your DNS more secure if it is not implemented on the client side, too. For example the web browsers doesn't check for DNSSEC without 3rd party validators like DNSSEC/TLSA Validator from CZ.NIC.

DNSSEC is a bit in the shadow of SSL certificates since SSL solves so many more problems than DNSSEC. One problem SSL certificates doesn't solve is rogue Certificate Authorities or improper confirmation of identity during getting the certificate, of which both may cause a valid and chained certificate to be issued to wrong entities. This may be one example case you were looking for.

Therefore, combination of DNSSEC and SSL makes it harder to counterfeit certificates. With a TLSA record in DNSSEC signed zone the certificate must be authorized in two independent chains. It is less likely that a rogue party can access them both. If you implement both and force your clients to require them, you are using DNSSEC in a useful way.

Community
  • 1
Esa Jokinen
  • 43,252
  • 2
  • 75
  • 122
  • I largely agree but just want to note that DNS is a protocol of its own and is used in wildly different contexts. Thus, if we manage to fix DNS itself rather than attempting to work around its deficiencies in other protocols that would actually fix more problems in the end. (Ie, using SSL/TLS for some other protocol fixes a different set of problems, any overlap is specific to that protocol.) – Håkan Lindqvist Apr 06 '15 at 13:09
  • @EsaJokinen Yes, I would like to set up a lab and execute the hack as a demo to encourage industry peers to implement dnssec which is why I was seeking the method name, to assist with googling. – nix Apr 06 '15 at 18:45
  • In this demo environment you could simulate rogue CA by installing an extra root certificate and signing a certificate with it and... well, probably you already got my idea of the rest. – Esa Jokinen Apr 06 '15 at 18:50
0

I would say it essentially boils down to what you already mentioned.

If you have DNSSEC implemented on both ends (a validating resolver and a signed zone), then DNSSEC prevents a man in the middle from altering the response without detection as well as avoiding the risk that a non-MITM attacker may win the what, for unauthenticated data, is a simple race of guessing the port and transaction ID before the real response arrives.

Having properly authenticated data also makes it feasible to use of DNS for additional things which are even more reliant on being able to actually trust the data, such as DANE (TLSA), SSH fingerprints (SSHFP), etc.

Community
  • 1
Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90