Status Update - Recursive resolving
Ugh. You probably know this. You’re working hard, but joyful on a certain project. At sometime during the day you boss comes in your office asking you to write a report on this or that. Not only you have to do these boring thing now, you’re also told to not “just put it off for the sake of writing more code”.
Well, of course your boss has good reasons to do so. Summarizing will not only help people around you understand what you do, what you want to achieve and what they can do to support you, but recapturing your own work might also gives you a new view on your work and in the end might make it even better. However in the moment where the report is due, it always seems unreasonable and useless, doesn’t it?
What happened?
Last status post is already two weeks ago. There must be something to report!
- minidns is now able to create output that is easily comparable with the output generated by the
digtool. This does not only come very handy when debugging the parsing results, but also makes output more valuable to expert users. (The output is not 100% RFC compatible, see here why). - As minidns supports both Android and desktop Java, it is able to handle Android specific ways to retrieve the stub DNS server setting. However these methods caused unreasonable overhead when performed on non-android systems. minidns now contains a proper platform detection to not call these Android specific routines on non-android systems.
- To allow the proper testing announced in the last status post, minidns was refactored hugely and now has support for arbitrary network request backends. While this is normally just UDP and TCP (as announced last report), it is possible to inject our test framework there. Additionally custom network backends (like using the Tor network to resolve
.onion-domains) can be injected there.
This was more generic contribution to the minidns library. When it comes to the project topic, there is also progress to report.
- Support to parse NSEC3 and NSEC3PARAM records (see RFC5155) for signed denial of existence was added. These are not used yet, but parsing them is a requirement for later usage.
- An initial version of a recursive resolver was added. Although it is already fully functional, it might have bad performance in certain circumstances.
What will happen?
A first DNSSEC specific code is already in the minidns-dnssec subproject in my working repository branch. With the recursive resolver being up and running, the base to work on the real DNSSEC part is done. So we can expect first DNSSEC features to arrive in short time.