
1.7.x or later
=====================

Testing:
---------
Would be nice to formulate some unit tests where they make sense, espcially libgdnsd stuff, config/zonefile parsing (w/ bad input cases) without launching whole daemon, perhaps packet parsing broken out from dnspacket.c too.

Documentation:
---------------
Really need to get with something like doxygen going for the plugin API.
I've pretty much settled on sticking with POD for the rest for now, the competitors (txt2tags, reST, asciidoc, etc) just don't stack up on various utilitarian needs I have for exporting and such, at least not enough to be worth converting for.

Config format:
---------------
The decision to invent the "vscf" data language + API for gdnsd config was made under some assumptions that are no longer true, the primary one being that we might re-use the language for zone data (which makes easy support for all possible, legal domainnames and labels important).  With that requirement out of the way, it makes sense to re-examine whether there's a better data language out there we could use.  JSON makes a lot of sense, and was almost chosen at one point in the past as well.  A big benefit would be maintaining less gdnsd-specific code, and being able to generate/validate/manipulate gdnsd configs from scripting languages easily.  There are a couple of possible pain-points with JSON though, some of which may just depend on specific implementation details of the parsing library:

*) JSON does not natively support comments (at least one parser supports C++/Java-style //comments though)
*) JSON hashes are not ordered, and some of our current vscf config cares about hash key order
*) JSON is natively UTF-8, and we might have to deal with conversion for some use-cases (e.g. config values that match ISO-8859-1/CP1252 city/region names in GeoIP databases).
*) JSON can't legally encode a NUL byte in scalar data, because it's natively UTF-8 with only Unicode escapes.  This means people won't be able to configure things related to ugly-but-legal DNS labels that contain NUL bytes, but I think I don't mind that.

Related: config should support include-files, shouldn't be too hard regardless of format/parser.

Related: if we stick with vscf, refactor the API into a new namespace (vscfg_?) with compat wrappers for transition.  Mostly this is to get rid of deprecated stuff, stop supporting embedded NULs in hash keys and string data, stop returning everything as const, etc.  Keep in mind the comments at conf.c:146 as well about dname keys.

Lua:
----

Lua might be an interesting language to fill two roles: a scripting language for monitoring plugins and a configuration language that's both more flexible and more standardized than vscf.  Lua-based config could be quite powerful actually, given that you could write code constructs to generate complex, repetitive configuration stanzas in Lua code in the configfile itself.  We could even have a zonefile syntax extension to embed Lua-generated RRs as well.

As for config syntax, it might be within reach to both (a) implement a new config language using Lua objects, and (b) implement a lua script which parses the existing vscf language (a few odd corner cases aside) into the same config object the new config language uses, to allow for backwards compat for a major rev or two during the transition.

A downside (with any script language, not just Lua) is introducing an external versioned dependency for gdnsd.

Monitoring upgrades:
----------------------
Track more stats on the HTTP status page (per-resource ok/fail counts over various windows?)
Come up with a derived "monitored weight factor" that scales from 0.0 -> 1.0 based on recent monitor history (1.0 being UP, 0.0 being DOWN, and the middle values representing various DANGER cases), and then provide some way to hook that to plugins so that they could optionally use it to scale configured, static weightings?

Control Channel:
-----------------
Be nice to have a listening unix socket from the main thread for command+control.  Cleaner option than signals for shutdown and stats on request w/o http are the first obvious targets.  Beyond that, might be nice to offer an interface here to the core monitor code to force a resource up or down temporarily, and could tie in with other dynamic features down the line...

Plugin stats ouput:
----------------------
Plugins should have a way to report stats counters back to the core code for inclusion in the HTTP status page...

AXFR, and runtime zone reloading in general:
----------------------------------------------
Realistically, AXFR is pretty far down the priority list.  People can use an external AXFR receiver if they want, taking advantage of 1.8's dynamic zone support.

Other zonefile formats:
-------------------------
Load other zonefile (or zone data in general) formats?  The BIND syntax sucks, but I'm keeping it as the default, it's too widespread not to.  However, the zonefile scanner is mostly cleanly separated from the rest of the code, and it wouldn't be that hard to add support for more formats (djbdns? a SQL connection?).

Stuff from conversations w/ Paul Dekkers: --------

DNSSEC:
--------
For the second time, someone has seriously asked about DNSSEC support.  Given the way the world is going, I may just have to implement it even though I don't like it.  Perhaps it can be kept mostly-separated the way DNSCurve was, but I doubt it.  I may take a stab sometime in 2012.  If implementing it is excessively intrusive on features or performance for non-DNSSEC users, I'm likely to never merge the branch though..

Proxying:
---------
A dns proxy server would be interesting to implement, separate from gdnsd.  Not a cache, or a user-visible part of the normal hierarchy of servers.  More like something an administrator would use to filter/forward/reverse-proxy into a set of real DNS servers.  The use cases would mainly be loadbalance/failover sets (for DNS servers with large volumes of traffic), or to use differently-featured servers for different requests, etc.

I'd imagine the proxy could choose a destination server based on any sort of matching (regex on query name, query type, presence of EDNS and/or various flags or edns options), and perhaps also implement feature-filters.  Feature filter example: proxy front always supports edns-client-subnet, splits two zones to two different backend servers, only one of which implements edns-client-subnet and the other serves static data.  So the option passes through to the supporting server, and gets stripped for the other (and set to /0 scope on the response).  You could do data filters too (e.g. a backend only serves example.com, and you filter-translate requests for example.org to use the example.com data).  Policy filters would be interesting as well (strip all AAAA response data from responses that weren't explicitly AAAA queries), as would using it to implement View-like stuff (requests from 10/8 go to serverA, rest of the world hits serverB).

An interesting side-effect of doing this as a second daemon within the gdnsd project would be the opportunity to refactor a lot of our core code for re-use, cleaning it up in the process.  Perhaps that in turn would open the gateway to make it feasible to support dnssec as a separately-compiled variant of the daemon, sharing most code where appropriate and not really affecting the non-dnssec daemon much.
