DNSSEC is already a well-established technology, which extends the DNS protocol to provide integrity and authenticity. This enables new types of applications and functionality like:
- Verify a remote server SSH fingerprint using SSHFP record in DNS (RFC 4255)
- Verify a TLS certificate offered by the remote server using DANE and TLSA record in DNS (RFC 6698)
- Get IPsec keys for a particular remote host automatically using IPSECKEY record in DNS (RFC 4025)
- Get X.509 or OpenPGP certificates using CERT record in DNS (RFC 4398)
- Verify that a specific Certification Authority is authorized to issue a certificate for a particular domain, using the CAA record in DNS (RFC 6844)
The DNSSEC configuration and deployment on the server side is a well-understood and for the most part, an already solved problem. The applications using DNS records mentioned above are mostly useful on the client side. While the client side configuration may seem trivial, it is non-trivial for mobile devices roaming across various networks (at the airport, local cafe or at work) which may be OK for DNSSEC, broken or misconfigured. These networks can also apply various policies, e.g. dropping DNS packets larger than 512 bytes. Therefore, on such mobile clients, there is a need for a software, that would test the network on each network configuration change and reconfigure a locally running validating DNS resolver in order to provide DNSSEC validation.
- Make yourself familiar with DNS protocol and DNSSEC extension of DNS protocol.
- Analyze possible issues a client device can face, when it is moving across different networks and still wants to perform DNSSEC validation (mainly RFC 8027 – DNSSEC Roadblock Avoidance).
- Analyze existing solutions and implementations trying to solve the client side DNSSEC deployment (stubby, dnssec-trigger).
- Analyze which DNS resolver implementations (e.g. BIND, Unbound, dnsmasq, Knot Resolver, …) are suitable for client side DNSSEC deployment.
- Analyze which network configuration software (e.g. NetworkManager, systemd-networkd, network initscripts, …) is commonly used in Linux distributions (Fedora) and explore ways of integrating a 3rd party software with them.
- Design and implement in a chosen language a proof-of-concept application with the following properties:
- Must be able to react on any network configuration change on the system.
- Must be able to integrate with various network configuration software (e.g. by plugins) and provide an external API (ideally DBus).
- Must integrate with at least one, ideally NetworkManager.
- Must be able to integrate with various DNS resolver implementations (e.g. by plugins).
- Must integrate with at least one, ideally Unbound.
- On each network configuration change, the application must be able to test the connection properties and based on results of the tests configure the locally running DNS resolver to be able to perform DNS name resolution and DNSSEC validation.
- Must implement various fall-back mechanisms, in case the local DNS resolvers (provided usually via DHCP) are not usable for DNSSEC validation.
- Must provide a way to handle Captive Portal.
- Must provide a basic user interface describing results of performed tests and configuration used for the local DNS resolver.
- Should handle also split-DNS configurations (e.g. when the client is connected to a VPN which provides a different DNS resolver and a domain name handled by it).
- Should properly configure the DNS resolver, so that reverse DNS queries are routed to the right DNS resolvers, based on the IP routes which were provided by the same network connection as DNS resolvers.
- Package the implemented application as a RPM package.