This page is just random ideas. Some are crazy, some are impractical, and some are just bad. Hopefully some are interesting!

  • Initial results of resolver performance research
  • Modularity ideas
  • Enable DNSSEC by default (including for authoritative servers)
  • Optional checking for new versions (perhaps via DNSSEC-secured TXT lookups?)
  • Some sort of optional "call home" so we know what versions are in use -- these reports will be used for the release engineering checklist
  • STUN-like tool for DNS
  • UPnP support
  • DNS-specific language for hooks (like bpf or Lua)
  • Fine-tuned access control rules maybe with conditionals
  • Integrate with OpenDNSSEC
  • Allow DNSSEC to be turned off for a single zone at a time
  • Deny specific queries rather than an entire IP
  • Put triggers on counters
  • Integrate with glibc DNS NSS
  • CommandLineTool
  • Better user experience when resolver in /etc/resolv.conf goes away
  • mDNS/Bonjour support
  • minimum cache ttl (some other DNS servers offer this?)
  • minimum ncache (negative) ttl (some other DNS servers offer this?)
  • run as much as possible without any root superuser needs
  • privilege separation, chroot, change uid/gid by default (if root is needed at startup)
  • if zone files are used as a data store, cache the checksum of each zone file to detect changes even if SOA serial is not updated
  • way for stub resolvers to use truncated responses if they only want one record (usually A or AAAA)
  • cache plugin (choose your own cache backend)
  • WOL support
  • a way to set an ACL for a zone so that administrators can use TXT records to document host meanings, but only have those visible internally
  • ability to manipulate TTL of cache entries directly
  • idea from Jelte:

Not directly related to this, and I forgot what caused the idea, but I had an idea for creating a b10-config command line wizard, which creates a basic setup with a few well-aimed questions.

  • idea from Eric Ziegast:

Let me load a list of forwarders from a config file and pseudo- randomly forward DNS requests to one of the servers in that list.

While this looks like load balanced forwarding, it's really for query source obfuscation across a large pool of recursive servers. Good guys can use this through SIE. Botnet operators can use all the open recursive nameservers in the world.

  • idea from Eric Klein:

In our corporate DNS environment we have a system that tracks the MAC addresses of machines (for populating DHCP config files, among other things) as well as some data gluing hosts to networks together. My suggestion here (these would be basically non-mobile desktop-type systems), was that we use some code to pre-compute the SLAAC address that the desktop will assign itself, and statically pre-populate the same BIND configs that we use for IPv4 address mappings for the same desktops.

Essentially I'm wondering if other folks might like a $GENERATE sort of thing to take a list of MAC addresses and generate the SLAAC addresses given a prefix. I think this isn't necessarily so easy since you'd need an association of hostnames with MAC addresses. But I know others are much smarter than I might be able to think of something clever, if it's a simple $IPv6IID(mac:addr) special directive.

  • Idea from Marco Davids:

I always wondered why there is no option to disable ANY-queries on an authoritative server.

Unless I am missing something here, it should be safe to return a REFUSED for them (I was told that Postfix is using them for some obscure reason, so maybe I am talking rubbish here).

In any case, disallowing ANY-queries *might* perhaps be considered in the combat against DNSSEC based amplification attacks.

  • Produce a warning on a zone where the SOA TTL is less than the negative cache TTL, since the actual negative cache TTL is the minimum of those two values.
  • Idea from Carsten Strotmann:

does anyone had the idea already to externalize/present the BIND 10 configuration as a RFC 1035 master zone file? that would feel natural to DNS admins, would be a way to replicate configurations, could be make secure using DNSSEC etc etc

  • Idea from Leo Bicknell:

A common problem is having a TTL of 12 hours and not lowering it before changes so zones end up having inconsistent behavior for 12 hour periods of time confusing a lot of non-technical folks.

Obviously the answer is to reduce the TTL, but I started thinking about how all of these are scheduled and started to think.... It would be useful to have a feature to specify when a DNS record changes. This may require something like BIND 10's SQL backend to be practical, but basically the user should be able to put in:

www IN A until 2011-10-01-12:00:00 then

Now, if the TTL is 12 hours, more than 12 hours before the switch date normal records for are given out.

  • Use TCP to send NOTIFY to secondaries where we need to notify about a lot of zones.
  • Do not send NOTIFY at all for zones that have not changed.
  • Idea from Jörg Dorchain:

Allow recursion only for specific domains. So, set the ACL to allow recursion for EXAMPLE.COM but not for other domains.

  • Idea from Jeremy Reed:

It would be nice to have a simple, intuitive command line tool, that is not nsupdate(1), to make changes to zones dynamically to datasource (let's assume maybe not using SQLite3 so sqlite3 interface is not an option).

  • Ability to configure server behavior when a zone expires; so rather than simply stopping serving the domain, perhaps send an e-mail or perform some other action as a zone starts to get stale, possibly continue to serve an old version of the zone, or try XFR from another server, or even use DNSSEC domain-walking to get the zone from another authoritative server
  • Checks can be made across zones if both zones are present in BIND 10. For example, a lame delegation can be spotted if both EXAMPLE.ORG and CHILD.EXAMPLE.ORG are served by a single BIND 10 instance. This can also spot broken DS records, and bogus glue.
  • Idea from Peter Koch:

That said, being able to specify a mapping between zone name and file name ( as in "zone/%f", "db.%f", or "" might help sources with lots of zones - but at the same time they could automate the maintenance of the config file, keeping the guessing magic outside the name server.

  • Idea from Jeremiah Daniels

"know what would be kinda cool? If bind10 had a way that when you add an IPv6 AAAA record, it automagically generated the reverse PTR... cause IPv6 IP management is a pain."

  • b10-rndc (See ticket #2495)
  • Some ideas from Martin Kealey
    1. generate records based on matching patterns in the name:
      $MATCH *.*.*.* PTR $4.$3.$2.$
    2. generate PTR records by scanning for AAAA & A records in hosted zones:
      $GREP *.*.*.* A $4.$3.$2.$1 PTR $N
    3. a scripting language interpreter:
      $CALL * PYTHON reply(0,'IN','CNAME','other.$')
  • extend listen_on for tcp only, so can have resolver only do tcp for public queries and can use udp and tcp for internal network. (Jeremy)
  • Perform DNSSEC lookups in parallel

XML stats

  • fine grained XML stats (not just all but request individually stats counters)
  • maybe use lighter weight XMl writer (see Libraries page)
  • see StatisticsIdeas


  • servers complain about problems to stderr by default
  • choose logging channel via the command line
  • clear and unique log entries for every type of DNSSEC problem, use for testing; if too costly, then make it a compile or run-time option to not do the checks needed for sometypes of logging.
  • per-view logging (if the concept of view is still relevant?) - ref bind9 bug ticket
  • unique log message for every log message (no more having same messages)
  • unique identifier (like a number) with each log message to later have webpage or tools to provide further details for that "log message" (like Microsoft)
  • support for:
    • syslog
    • manage own files
    • stderr
    • windows events?
  • query logs; toggle query logs while live
  • if not specific query logs: ability to enable or disable specific log messages (per output_option? that way one could for instance log all queries and answers to a specific file)
  • change debug levels while live
  • should rotation or log file maintenance be handled by this or different tool?
  • logging as a separate component?

(Most of these ideas have been refined into a set of requirements.)


  • abstracted interface to the necessary crypto (so can use different than just openssl)

programmer functions

  • dns_getXbyY() interfaces

extra tools

  • bindtop -- display the top queries, clients, et cetera; and periodically update this information. Gather from fine-grained XML stats interface.

data structures


  • Query Tracing
  • Ring buffer - add each incoming and outgoing query to one or more ring buffers so that in the event of a crash there is a history of the last queries received and sent.
  • Synthesized Queries
  • cache also record who provided the data and when


  • Update multiple domains for a lease allocation
  • Cleanup DDNS when a lease is allocated
  • Create IPv6 reverse mapping from hardware address in IPv4 leases (and clean this up)

Task Backlog

Completed Ideas

  • bind-showtech, some way of gathering information useful for bug reports This now exists in the form is "isc-sysinfo".
  • Access control rules modified in real time with command line tool
Last modified 4 years ago Last modified on Jul 28, 2013, 8:28:45 AM