
1.9.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.

Stats upgrades:
------------------
Upgrade the stats-tracking code to be more flexible and do more by
default.
Plugin-generated stats, monitoring stats, per-"datacenter" stats, etc...
Build up a generic, internal API layer for querying all of the stats

Ditch the built-in HTTP server in favor of dumping the same basic data
to a JSON file on disk.  We could ship an example "gdnsd.html" which
uses some simple javascript to load the JSON data and display it in
some pretty format, and even refresh it occasionally.  The idea is if
you want this HTTP-based info, run nginx or lighttpd on your DNS server
and have it serve gdnsd.html (or your own similar UI code) and the
ever-changing JSON stats file.

DYNA/DYNC refactor:
--------------------
It's becoming increasingly apparent that the current design which
splits dynamic CNAME and A/AAAA into completely separate entities and
code-paths isn't working out.  It's much easier this way from the
perspective of the core code for e.g. dnspacket.c and ltree.c, but it's
very limiting when it comes to plugin features (we really need the
ability for plugins to mix-and-match, e.g. serve addresses when they're
up and fallback to CNAME to a static CDN provider when all addrs are
down as a last resort).

It's also always been a source of extra confusion and bug possibilities
at the plugin-code layer (getting CNAME-related calls when the plugin
isn't configured to do CNAME for a given resource, etc...).

Probably need to switch the model to just be a "DYN" record and let
plugins return either type of response.  Although I see little point
for other dynamic RRs, at that point we may as well implement them as
well just for future-proofing (e.g. PTR, NS, MX, etc...).  It shouldn't
be hard to keep DYNA/DYNC around as deprecated backwards-compat stuff
at the zonefile level, but doing it at the plugin-API level as well
would be complicated.  Probably more likely to just break the API
again, as I've never claimed it was very stable.

Monitoring upgrades:
----------------------
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, data
reload, etc.  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.  Also another
user of the new stats query API above.

I suspect we'd ship a basic gdnsdctl binary to interact with the
socket's protocol, but that also the protocol itself would be published
so that people can talk to the socket with other tools.  Expect
multiple clients on the socket (stream-mode, btw).  Need to think about
the perms issues on the socket, of course.  Maybe default them to
root-access only (which we confirm/fix on startup before dropping
privs), with a configurable option to use some other username or access
mode).

AXFR
------
Realistically, AXFR is pretty far down the priority list.  I've always
thought I should eventually implement it for completeness even though I
hate it, but lately it seems more and more people come around easier to
the idea of syncing zone data via external mechanisms (rsync or config
management in general, etc...).  Implementing AXFR receive at this
point would probably just mean an external, separate program that drops
updates into the dynamic zones directory.  AXFR send would be some
tricky (but not that tricky) updates to the dnsio_tcp code to handle
spooling out the zone data.

No easy way around AXFR send of a zone containing DYNA/DYNC, though.
We could skip those records, but then it's not really an authentic copy
of the zone.  We could just refuse to send those zones.  We could do a
special flag/signal over AXFR so that gdnsd can detect other gdnsds and
send them as an extension, but there's still no gaurantee that
geoip!foo means the same thing in the config files on both ends...

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?).  Update: the core code is
basically ready for this.  I even created a mostly-empty zsrc_djb.c
file since that's likely the first/easiest target.  Just needs
implementation.

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.
