Repository navigation
Add support for DNSSEC #7
Description
I know this is a long shot, that is not going to be easy.
Smack already has an issue requesting DNSSEC support (SMACK-366), and with DANE in mind, DNSSEC would be the required first step.
There are already two DNSSEC implementations for Java, one is from the Jitsi project called dnssecjava. The problem with both is that they are build as Resolver for dnsjava. But dnsjava, while being a mature DNS implementation, is not a really good match for resource constraint environments like Android (dnsjava's nameserver determination is also a problem on Android, which is much nicer solved in minidns). I've just put effort into moving away from dnsjava towards minidns since it's the better option especially on Android. so I'm not keen on going back to dnsjava.
Maybe, we could team up with Jitsi, convince them that they don't want to use dnsjava with Jitsi Android, and de-couple dnssecjava from dnsjava. I think we all agree that it's not a good idea to implement a security critical component from scratch/on our own, instead we should reuse existing code (dnssecjava). I think this would also be a possible candidate for a GSOC project 2015: "A DNSSEC enabled DNS resolver for Android".
Activity
rtreffer commentedon Feb 13, 2015
This was now suggested for GSoC. I'll give access to this repo and maven in that case. Or move it over to an org if wanted.
Valodim commentedon May 9, 2015
GSoC students are announced, any updates on this?
dschuermann commentedon May 10, 2015
@Valodim See http://xmpp.org/2015/04/xsf-gsoc-students-2015/
rtreffer commentedon Jun 5, 2015
OK, I just read through most of the DNSSEC RFCs....
DNSSEC comes with a quite some resource records. I'd guess they would be nice to have in the core, as they might be received by any client. (DS, NSEC, DNSKEY, RRSIG, ...)
Same for everything that is needed to enable a real client (e.g. EDNS, TCP and alike)
BTW: does anyone know how well UDP and UDP fragmentation are supported by e.g. android? What should be a safe udp payload size? What do other clients use?
There is this huge part of what-should-we-do for a real client. My thinking is that this will be huge. Ideally it would support up to a RFC-4033 "Validating Security-Aware Stub Resolver", right?
This sounds like a rather huge block that just some users will need. It's also required to allow configuration of at least one key (https://tools.ietf.org/html/rfc4035#section-4.4), which means it might not work out-of-the-box anyway.
This will be the critical part for a review, right? The thing that should never be screwed up :-)
I'm wondering what to do about obsolete crypto. Should this be regarded as "bad" data? Or cause a warning? What if the status quo moves differently than the RFCs? RFC 6944 lists some NIST ECC curves as recommended, although many people expressed their distrust against those curves (including technical summaries like http://safecurves.cr.yp.to/).
Is it correct to completely ignore the original and now obsolete DNSSEC RFC (2535)?
Valodim commentedon Jun 7, 2015
so no gsoc student?
yes, a validating security-aware stub resolver is exactly what we should be going for here. this will probably require support for tcp queries, too. reading the (relevant parts of the) dnsjava code will likely answer many of the other questions.
I wouldn't worry too much about which curves to support, all of that should obviously be handled by a library.
rtreffer commentedon Jun 7, 2015
@Valodim there is. @mar-v-in is happily adding records and features, see https://github.com/mar-v-in/minidns
Add support for DNSSEC MiniDNS#7
Flowdalic commentedon May 13, 2016
This first 0.2.0-alpha versions of MiniDNS with DNSSEC where uploaded to Maven Central. Read more about it http://geekplace.eu/flow/posts/2016-04-22-minidns-dnssec-alpha.html