YoDNSConf

After wrestling with optimizing the performance of large zone tables, I've decided to exclude domain redirects from the default.

While these are real zones which require administration, they aren't as high a priority, nor do they get edited as often.

In the new method of managing the list of zones via an actual zonefile, I'll set the categories or tags of zones with the ttl parameter, possibly using an id to category or tag mapping. The only limitation I can think of at the moment is the inability to assign multiple categories to each zone, though there could be some sort of encoding or mapping that goes on.

I'd really like to keep things simple, but flexible. Should a zone's categories or tags require an extra query?

IP and host name management is related to, but not identical to, DNS management. I'm thinking about storing and serving a list of domains or IP addresses or subnet masks over a simple network protocol, such as Redis or Memcached; or even DNS itself.

Yes... that's what I've done. I setup a private DNS zone which contains A records for every zone file I manage. Actually, I'm switching to TXT records, as even though I could achieve this with AXFR requests, I believe it will be simpler with TXT. Something like this:

$ORIGIN example.priv8.
$TTL 12h
@  1D  IN  SOA  ns1.example.com. email.example.com. (
              2010061201
              28800
              7200
              604800
              2400
              )
names 1 IN TXT "example.info"

While YoDNSConf can manually parse the file, other consumers of this data will be able to query the DNS server. I'd like to keep the service private, and I might be able to, but for convenience, I'll probably just use a zone that is incompatible with the internet at large (something without a .com, org, net...) and setup stub zones for my DNS resolvers.

I'm pretty excited about a new Ruby gem I've found which can directly parse BIND format zonefiles. Aptly enough, its called "zonefile", and can handle pretty much everything I need it to.

I've started integrating it into the Ruby/Sinatra branch of YoDNSConf, and so far, so good! The idea of manipulating raw zonefiles will make things much easier - I can even imagine using git to keep track of changes, and vlad to push them out!

I'm looking to optimize my content distribution network with GeoIP DNS services!

While it seems possible with BIND, I'm going to use PowerDNS. Errr... actually, it turns out that it is not possible to route by US states - particularly coasts - that would be nice!

Another change I'm making is to use BIND because apparently NSD3 isn't providing glue records for DNS queries where the target host's name servers are on another domain.

http://www.geoscaling.com also caught my interest, but I haven't tried it out yet.

Actually, I am going to use BIND9 - the acl and view capabilities make it fairly easy. However, I'm actually not going to use it for optimizing via geo-location, I'm just going to split requests so that all of my distribution nodes get used, without having to use a CNAME-to-multiple A setup.

view "north_america" {
      match-clients { US; };
      recursion no;
      zone "evenserver.com" {
            type master;
            file "/etc/bind/zones/evenserver.com.us.zone";
      };
};

acl "US" {
  3.0.0.0/8;
  4.0.0.0/12;
  4.16.0.0/16;
  4.17.0.0/17;
  4.17.128.0/22;
};

Seriously though, these acls with BIND9 are AWESOME!! They can also be used for internal networks - returning local addresses to local clients.

PROGRESS:

• I've confirmed that BIND is the right choice for me, but I've also realized I need to separate the geoip DNS distribution servers from the higher level static A record services.

Now seemed like a good time to make a tag in the YoDNSConf Subversion repository, so I've gone ahead with it. I recently fixed up the database while I was setting up the demo, so things should pretty much be in working order on new installations.

I've tagged 0.04 as a milestone, but refrained from branching it. YoDNSConf remains in active development so I'm not certain its worthwhile to spend the time to branch right now.

I'm really keen on this application and I think you would be too!

I currently use both CNAME and A name records all the time. However, I'm reconsidering how much I rely upon CNAME records.

I feel that they make sense for many HTTP records, but for some, I'm thinking that A records might be better.

But not just standard A records, A records that are defined by a YoDNSConf "A Record Reference".

How does it work?

This would look similar to a CNAME record in the YoDNSConf record edit page, but the user would choose from a preselected set of IP addresses. When the zone records are published (or in the case of MyDNS or PowerDNS using a RDBMS backend), an A record IP address is returned.

Why Use A Record References?

I host many low-volume DNS records which could benefit from the low-latency of a single A record. On the flip side, the IP address may change from time to time, and I'd like to be able to manage the records in an automatic fashion. I really don't like having to edit individual records manually one-by-one in a repetitive manner.

The YoDNSConf Demonstration is now accessible:

Web-Based DNS Management Demonstration

I'm glad to finally get this setup!

The YoDNSConf server is back online.

NOTE: The YoDNSConf source code is now hosted at Github:

YoDNSConf

My primary subversion server happens to be down at the moment, and I guess now is as good a time to consider switching to git.

However, since I run several open source projects, I should probably start with a smaller project than YoDNSConf. This is an important project to me and since I use it everyday as a production system, I think I'll wait until I iron out any bugs with git on another project.

I'm working on a couple of cool new features which should prove rather interesting.

First I've added some fields for back-end proxy server addresses for zone groups. This can be used to create routing paths for reverse proxies like NGINX or Pound, as well as mail relays for Postfix and popmap.re files for Perdition. So far I've only created templates for NGINX.

NOTE: While I currently use Perdition, I plan to switch to Dovecot at some point.