Good news - YoDNSConf, a Ruby on Rails powered domain and DNS management system, is now available for public use!
Try it out here:
Without registering, users can check domains. By registering, users can actively manage domains.
I’ve been hard at work on YoDNSConf tonight and I’m pleased to report some major improvements:
- Integration of the whois gem
- Tracking of expiration dates
Lots and lots of view updates as well:
# On branch master # Changes not staged for commit: # (use "git add..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Gemfile # modified: Gemfile.lock # modified: app/controllers/zones_controller.rb # modified: app/models/zone.rb # modified: app/views/zones/_sidebar.html.haml # modified: app/views/zones/index.html.haml # modified: app/views/zones/show.html.haml # modified: config/deploy.rb # modified: lib/tasks/utilities.rake # modified: public/stylesheets/compiled/screen.css # # Untracked files: # (use "git add ..." to include in what will be committed) # # .sass-cache/ # app/models/whois_record.rb # bugs/issue-a781cdda38f6f2e2fbb7fc974b368f827e24e987.yaml # db/migrate/20110913020302_create_whois_records.rb # db/migrate/20110913035633_add_expires_at_to_zones.rb
Next up will be integration of the zonecheck gem. With those in place, I plan to create some reports about the domain portfolio.
After that… engines! What engines do I plan to make? At first, just a small component to track extremely basic traffic data. After that, who knows?
I’m gung-ho on the Ruby on Rails 3.1 bandwagon, with many of my open-source projects switching to Rails 3.1, including:
I’m also planning on porting these ones as well:
I’ve actually done some work on porting YoDNSConf to Rails3, but there is still plenty to do. Feel free to contact me via github if you’re interested in helping out with this open source project and learning about the awesomeness of Rails 3!!
UPDATE: I’ve made much progress, and YoDNSConf will soon have a public service for checking DNS for hostnames, similar to how DNS stuff used to work.
For example, it will check the nameservers from public DNS resolvers, ensure that mx records are hostnames and not IP addresses, and that a www A record exists.
I am renewing my interest in YoDNSConf, and this time I’m again looking to create a command line interface to a DNS database, as well as directly parse zone files via Ruby’s zonefile gem.
I hope to have it operate ghost, the rubygem that makes it sort of easy to manipulate one’s /etc/hosts file.
Ghost works in harmony with the trend in commands and sub-commands issued on the command line. Joey Hess describes the trend well in his post: command composition.
Perhaps the yodnsconf gem could work something like this:
yodns list example.com +-----------------------+------+-------+------+ | zone | type | ttl | name | +-----------------------+------+-------+------+ | www-c.evenserver.com. | IN | 28800 | www | | www-b.evenserver.com. | IN | 14400 | www2 | +-----------------------+------+-------+------+
It should be able to access a dotfile for settings, and be able to do some globbing, as well. I’m torn about how it should, or could do some caching of the zonefiles, to either a database (like a sqlite3 db), or to a json file, or something similar.
I’ve spent a couple hours on this and its actually working already. Awesome!
Next Steps
I’m planning on including grit for git / ruby revision control, and I’d really like to make the process much more interactive.
So far I am using Trollop, and its working very well. The DSL is a little clunky; seems like I have a lot of “Trollop::options” in my code:
cmd_opts = Trollop::options do
opt :type, "Record type", :default => 'a', :short => '-t'
end
UPDATE: I’ve created a github repo for this. NOTE: Its still alpha.
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!
UPDATE: Its worth mentioning that the zonefile gem does a great job of defining what properties each record type can have:
* SOA - :ttl, :primary, :email, :serial, :refresh, :retry, :expire, :minimumTTL * A - :name, :ttl, :class, :host * MX - :name, :ttl, :class, :pri, :host * NS - :name, :ttl, :class, :host * CNAME - :name, :ttl, :class, :host * TXT - :name, :ttl, :class, :text * A4 (AAAA) - :name, :ttl, :class, :host * SRV - :name, :ttl, :class, :pri, :weight, :port, :host
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.
Recent Comments