DNSSEC

The goals of this assignment are to:

  1. Learn how DNSSEC defends against DNS hijacking and cache poisoning
  2. Implement recursive DNSSEC resolution and verification

DNSSEC

Having seen various ways in which an attacker can subvert the DNS, we now turn to studying how to prevent these attacks. DNS Security (DNSSEC), defined in RFCs 4033, 4044, 4035, 6014, and 6840, extends DNS to support cryptographic verification of the following security properties:

  1. integrity of DNS queries and responses,
  2. authenticity of DNS responses, and
  3. authenticated denial of existence.

In this assignment, you will learn how these properties are obtained by implementing recursive DNSSEC lookups.

DNSSEC Recursive Resolution

In particular, you will implement a recursive resolver supporting DNSSEC from the above RFCs. Your recursor must listen for queries on 0.0.0.0:53/udp, carry out a verified recursive resolution from the DNS root, and return the result to the client. The result should follow the standard to indicate whether resolution was successful, and furthermore whether it was verified or not.

You may use the networking and cryptographic libraries of your choice. You may also use a library to parse and serialize DNS messages. However, you are responsible for implementing the recursive lookup algorithm and signature verification. RFC 4034 describes the format of the DNSKEY, RRSIG, NSEC, and DS messages as well as the basic verification algorithm. RFC 5155 describes the NSEC3 hashed denial of existence record.

Your implementation must support a large enough subset of DNSSEC to successfully service verified A and AAAA record queries for login.gov. Your implementation should also be able to verify a non-existent domain in the login.gov zone, e.g., dontqueryme.login.gov. Your implementation should also successfully indicate that an insecure zone cannot be verified, e.g., www.khoury.northeastern.edu.

You may find that TCP is required for your recursor’s queries.

Your recursor must not perform any caching of DNS records. However, it must implement standard entropy-based attack mitigations.

Your recursor must accept a TOML configuration with the following format:

[[root_servers]]
name = "a.root-servers.net."
ipv4_address = "198.41.0.4"

[[root_servers]]
name = "a.root-servers.net."
ipv6_address = "2001:503:ba3e:0:0:0:2:30"

[[dns_keys]]
key = "AwEAAcVnO2jZFx4756Rb/yAhJnsl72eemsObU43nclmXwqdJlp+kC5WQjGYkqLT5xkaUCPhkr4NKLLrIBZXeSGazc6gx/yrrMtUpXcQvax6kfDJPTu974OmeEbtjyyP7ZG5tUfSwNWt/4EuxDNmZTESG8jU0ZLjYIB11pK0gSXQbMVPyIyGtFGHMPx6UxWn6zUzpECWRFbqEvkA6Y13zeJ1jG2Rki/zs7a/o13FTl/kI9013Eh6l6Kc2zxbc14GS8fpM0/xQIrZZyeiXj/2C4RcsPeqWuNj9m0qSQrbrCZtLHb20U8x1uue4iwSX9y7LpwZd6vjYd1d6dgBa1Xxgc/TC+m8="
zone_key = true
secure_entry_point = false
revoke = false
algorithm = 8

Note that you may receive multiple root server definitions with either IPv4 or IPv6 addresses, as above.

Your recursor will be evaluated against a set of benchmark queries for both DNSSEC-secured zones as well as non-secured zones. You must assume that the grader is a non-validating stub resolver.

Your implementation will also be subjected to DNS hijacking attacks.

Recursor Container

Your attack should be implemented in a separate container that will be invoked with the following arguments.

docker run -it --rm --name=dnssec               \
    -p 53:53/udp                                \   # Expose DNS port
    netsec_dnssec_recursor                      \
    ${path_to_config}                               # Path to server configuration

Submission Instructions

Package your solution as a gzipped TAR archive. Your solution should expand to the following directory structure.

$ tree -F dnssec
dnssec
├── Dockerfile
└── src/

The source code to your solution should be contained in src/. Your Dockerfile should, when processed using docker, create a container image that runs your solution using the aforementioned command-line interface.

Submit the solution archive to Canvas.

© 2023 wkr