DNS Security Extension

  • "Fixes" some of the security threats associated with DNS by having names servers provide a digital signatures which are checked against their "parent," all the way up the chain until the root server. This creates what we call a Chain of Trust.

New Records

  • RRSIG (digital signature)

  • DNSKEY (public key)

  • DS (parent-child)

  • NSEC (proof of nonexistence)

  • NSECS3 (proof of nonexistence)

  • NSEC3PARAM (proof of nonexistence)

The digital signatures are used by recursive name servers (validating resolvers) to verify the answers received.

DNSKEY is the public key published in a given zone, while DS record is verifiable information generated from one of the child's public keys that a parent zone keeps on its child as part of the chain of trust.

DNSSECSteps.png

1) Recursive DNS starts a query and in addition asks for DNSSEC validation

2) Isc.org responds with an A record (nothing new) and a digital signature

3) Recursive name server now has to validate the signature and asks for the keys

4) Isc.org responds with the keys needed to validate the signature in step 2

5) Since we don’t just take isc.org's word for it, we must first validate the public key given by isc.org by going to the parent, org. Our DNS server will ask org for the information about isc.org

6) .org will respond with verifiable information and we can compare this with the information given from isc.org

  • This continues until we reach a server in which we take it’s word for it, usually this is a root server

7) We ask now .org for its keys (as we do not trust .org's word)

8) .org response with its keys, of which, we can verify with its parent ( . )

9) We ask .org's parent, root, for information about .org

10) Root responses and we can validate the information given to us in step 8

  • (11 and 12 would be the same process if we didn’t trust root and wanted to keep going up the tree, )

This establishes the Chain of Trust

  • Just to recap, the rcursive server will save key informaiton about a "trusted" member of the tree. In most cases the trusted member is the root server.

  • This is what verifies the root server keys by comparing RRSIG and the DNSKEY with the saved key information.

Preparing a Recursiver Server for DNSSEC

  • add a option to allow DNSSEC

DNSSECOne.png DNSSECTwo.png

Testing with dig and delv

  • dig (Domain Information Groper)

DNSSECThree.png

  • delv

    • similar to dig but tailored towards DNSSEC

DNSSECFour.png

How are answers verified

  • All DNS record messages are run through a hash function which is then encrypted by the private key create a signature.

DNSSECFive.png

  • When the name server responds to a query, it passes both a plan text message and the digitial signature
    • The recursive name server will hash the plain test message to verifiy
      • We can get the correct hashing type from from the A record of the response

    • The recursive name server will then use the DNSKEY (public key) to descrypt the RRSIG (digital message) which we then can compare to our previously hash plain message

DNSSECSix.png

Key Values In a RRSIG

DNSSECSeven.png

  • The 5 is the hash algorithm
  • Time stamps
    • Signature Expiration: 20141029233238
    • Signature Inception: 20140929233238
  • key ID: 4521

    • This wil correspond to DNSKEY (public key)

Trust Anchor Key

  • Recall that you must save locally the key information of a server in the chain of trust that you trust

  • if dnssec-validation is set to yes instead of auto, you will have to provide your own anchor key

  • You will then have either add a trusted-keys option in the bind configuration or have it in a serperate file that is included in the main configuration file

DNSSECSEight.png

EDNS (Extension mechanisms for DNS)

  • DNSSEC requires larger packets (size) than plain DNS, EDNS allows this
  • The majority of DNSSEC traffic will be larger than the allowed MTU and therefore must be fragmented (TCP), EDNS allows larger DNSSEC packets there by stopping them from being fragmented
    • Appropriate firewall rules must be added to allow this type of DNS response

    • NOTE: EDNS is used by a hop-by-hop basis and therefore could possibily be unsupported upstream, resulting in fragmented DNSSEC responses leading to firewall problems

Creating Needed Signing information

  • The needed key information must be generated and uploaded to the parent

Signing1.png Signing2.png Signing3.png Signing4.png

  • The above commands can generate both Zone Signing Keys (ZSK 256) and Key Signing Keys (KSK 257)

Signing5.png Signing8.png

  • You will then have to make changes in the configuration file to specify the correct keys for each zone

Signing6.png

  • Key-directory: the file holding the key

  • inline-signing yes|no : allows name servers to sign zones transparently

    • Meaning a server can load or transfer an unsigned zone and create a singed version of it which can then answer all DNSSEC queries without altering the original unsigned version.

  • auto-dnssec maintain: allows a server to automatically sign and re-sign zones after the initial configuration at the appropriate time as determined by key metadata

Signing7.png

Key Maintenance

  • All of the keys will have set TTL and therefore must be changed at some point. This can be a simple fix to some DNSSEC issues

Nice reasources

  • DNSKEY to DS record

    • Allows you to see if the parent's DS record matches the child's DNSKEY

https://filippo.io/dnskey-to-ds/

  • Visual DNS trackers

http://dnssec-debugger.verisignlabs.com/

http://dnsviz.net/