Well, I should have listened to everyone who warned me about UltraDNS’s obscene prices. But I figured it’s only DNS, so how much more could they be compared to their competition? $50 per month? Maybe $100? Boy was I surprised to find out that UltraDNS’s prices are literally 10-25 times more than everyone else’s! Hilarious…
I’ve actually been a DynDNS customer since the late nineties or so (I have free custom DNS service for life for making a donation to them back when they were a much smaller company), so I had looked at Dyn.com‘s products before. I just must have gotten confused with all their different websites and DNS products, because I somehow got the impression that the DynDNS API wasn’t powerful enough to do what I wanted to do. I was absolutely wrong. After having written command line clients for both APIs (see ultradns4r, and now dynectr4), I think I speak from authority when I say the Dynect API is every bit as powerful as UltraDNS’s. And at 1/10th – 1/25th the cost of UltraDNS, going with Dynect is a no-brainer. But I’ve digressed long enough.
I wrote dynect4r for the same reason I wrote ultradns4r; I wanted to be able to manage all my DNS records via the command line. And now that I’ve learned how to package Ruby projects as gems, you can simply…
and then do things like…
dynect4r-client -n test.example.org 1.1.1.1
Since the key feature of this project is the command line client, the actual library behind it is a pretty simple wrapper around rest-client. If you’re looking for something a bit more powerful to use in your own Ruby projects, you may be interested in dynect_rest by Adam Jacob from Opscode. We actually discovered each other’s projects last night in #chef, and realized that it would probably be a good idea to pool our efforts eventually.
I just spent the last week or so learning more about SOAP than I ever wanted to know. ;-) Fortunately, the result of that hard work resulted in something that might benefit the EC2 community.
I am pleased to announce ultradns4r; a Ruby library and command line client for the Neustar UltraDNS SOAP API. I created this tool to alleviate the pain in dealing with EC2′s dynamic hostnames and IP addresses. Since it allows editing of arbitrary DNS records via the command line, it can be used to make EC2 instances update their own DNS records.
Lessons Learned
- If you need to do SOAP in Ruby, just use Savon. Trust me on this.
- WSSE authentication is a complete pain in the ass. I was unable to find any SOAP library (Ruby, Python, or Perl) that could authenticate with the UltraDNS API servers out of the box (Savon included). I ended up having to build the entire WSSE header manually in order to generate the exact XML needed.
- Apparently, element order sometimes matters with SOAP! This is something I never expected, considering that (last I knew) the XML spec does not even allow you to enforce element or attribute order. This was also the cause of a lot of my WSSE problems. I found that for example, if the Password element came after the Nonce and Created elements (which is the case if you use Savon’s built-in WSSE authentication), then authentication would fail. Could this have been the result of having a buggy XML parser on the server side? In any case, this is one of those annoying issues to be aware of.
Published on
2008-10-22 in
DNS.
Look at this round-robin DNS example and ask yourself what you would expect to happen:
test.example.com. 60 IN A 127.0.0.1
test.example.com. 300 IN A 127.0.0.2
I expected that one record would be cached for 60 seconds and the other would be cached for 300 seconds. The reality is that both records will be returned with the same TTL, namely the lowest one. I haven’t been able to find this documented anywhere, but I have confirmed this behavior on both Microsoft and BIND DNS servers, so I’m assuming it’s some sort of a standard. I’ve also only found one mention of this (with a reply from a Microsoft MVP who obviously doesn’t know what he’s talking about), so I wonder how many other people are aware of this.
Published on
2008-03-12 in
DNS and Rants.
One of my biggest IT-related pet peeves is a broken DNS infrastructure. Since nobody seems to know how to implement this properly, I have decided to write a little howto to help put an end to the insanity.
- Don’t just use whatever the hell domain name you want and justify it by saying “we’ll only be using this domain internally, so it doesn’t matter if we actually own it or not.” That’s just as dumb as using someone else’s public IP addresses on your LAN, and if you don’t understand what’s wrong with that, you’re fired. Make sure the domain you want to use is unique on the internet, and register it.
- Do use a standard TLD; not that .local bullshit. Using a non-standard TLD like .local is a great way of showing the world that you have absolutely no taste (see below).
- Don’t go out and register two entirely different domains (e.g. example.com and example.net) for your internal and external namespaces. This is unnecessary, will confuse your users, and will tell the world that you don’t understand how DNS works. Just use sub-domains (e.g. hq.example.com, office.example.com, etc.) for your internal networks, and reserve the root domain (i.e. example.com) for your external resources.
- Do use different internal and external namespaces. If your external namespace is example.com, don’t use example.com for your internal (i.e. Active Directory) namespace too. Otherwise, you’ll run into problems when your internal users can’t resolve external resources (like your website which may be hosted off-site). If you were stupid enough to make this mistake, one solution is to mirror all your external resource records on your internal DNS servers, but then you’ll have to add/change every record in two places.
- Do run your internal and external namespaces on separate servers (or at least in separate views). It’s not a good idea to make your internal resource records available to the whole world in the first place, but if you’re using proper private IP addresses on your LAN, this won’t help anyone access your servers over the internet anyway.
Before you ask, if you think you have a good reason not to follow any of the above rules, you are wrong. Don’t do it. I’m begging you.