I am working on coming up for ideas on a final year project for my CS major. One of the ideas suggested by a lecturer that he would be interested in supervising would be an exploration of the application of ID-based encyption to securing DNS. From my preliminary research, I am leaning towards a project whereby I attempt to marry DNSSEC with this encryption standard.
My idea was that I might be able to use the simple DNS levels of BIND9, minus DNSSEC, and build on top of them a customised DNSSEC-like scheme. I would presumably have to modify parts of the library too, in order to use the features of RFC 2535 such as the KEY and SIG RRsets with my new scheme. Or perhaps the best approach is to edit how DNNSEC is implemented in the library and attempt to rip out OpenSSL and replace it with hooks to my own mini-encryption library? Has anyone any experience on working with the BIND library that could tell me how bad of an approach this is, how the library lends itself to extensibility, etc.?
Please clarify whether when you say “securing DNS” you mean:
The three features are more or less completely orthogonal.
TSIG does the first – it prevents an individual packet from being modified while it’s in transit, and only works from hop to hop.
DNScurve does the second, and therefore implicitly the first too (since if a packet is modified the decryption won’t work), but isn’t standardised. It’s an interesting idea, but it’s a very long way from any significant deployment.
DNSSEC only does the last of the three. It is intended to provide an end to end cryptographic proof that the data received by the DNS client is identical to that contained in the authoritative server, regardless of how many recursive resolvers were involved.
From the Wikipedia page ID-based encryption appears to be about securing messages between two parties, and not about signing data. If that’s correct, it’s closer to TSIG or DNScurve than to DNSSEC.