I got no response from joker.com, and they don’t list a telephone number. They took my money and ignored me. This pissed me off, but not as much as the fact that the domain name could not be transferred to another registrar for 60 days, making it useless to me. At this point I was furiously planning my complaint to ICANN. Then, about 27 hours after I logged the support request, my domain re-appeared and I got no explanation as to why they rolled back the registration to start with.

This reminded me of a fight about two months ago on the IOZ mailing list about Uniforum’s overly strict requirements on name servers during the registration process… something about checking rDNS for the zone name servers, a problem you should almost never have.

Even IS Labs has it’s own little corner for Uniforum hate. The most popular idea (according to IS Labs’ ranking) is to “Drag uniforum registration process into this century”.

A critic is a legless man who teaches running.
– Channing Pollock

I have personally also been guilty of criticizing Uniforum behind their backs, but I think the web-services enabled DNS nirvana that some people have in mind (especially one where there is a separation between registry and registrar) is badly overrated. Here is a list of reasons why, I’ve concluded, we should count our blessings when it comes to the CO.ZA domain:

• Uniforum’s integrated registry/registrar model simplifies support, and their prices aren’t high enough to warrant introducing registrar competition. In fact, inserting middlemen is likely to increase costs.
• Using human-readable plain text messages between applications is good practice according to time-tested UNIX philosophy. Your XML-serialized RPC over HTTP (“web service”) is great, until it breaks and you have to debug it.
• I actually prefer paying an invoice manually once a year over having some opaque payment processing system fumble with my credit card details. It’s more effort, but it places you (the customer) in control.
• Uniforum’s engineers are possibly somewhat stubborn (from what I can tell, based on IOZ posts), but, their system works if you meet their requirements. I can respect that.

Python to the rescue. The dnspython module has support for parsing BIND zones, and rendering them without the shortcuts:

#!/usr/bin/python
# bindnorm.py - "normalise" a bind zone file by expanding relative names.
# Simeon Miteff <simeon@localloop.co.za>
# Tue Sep 23 10:03:35 SAST 2008
import dns.zone
import sys
 
if len(sys.argv)<2:
	sys.stderr.write("Usage: %s [zone fqdn]\n" % sys.argv[0])
	sys.stderr.write("Example: %s example.com < db.example.com > norm.db.example.com\n" % sys.argv[0])
	sys.exit(1)
 
zone = dns.zone.from_text(sys.stdin.read(), sys.argv[1], relativize=False, check_origin=False)
zone.to_file(sys.stdout, relativize=False)

To use it, you’ll need to install dnspython first. Fortunately, on Debian or Ubuntu, it’s just an apt-get install python-dnspython away. Running this little script with the example zone above as input yields:

example.com. 259200 IN SOA server1.example.com. hostmaster.example.com. 1 28800 7200 2419200 86400
example.com. 259200 IN NS server1.example.com.
example.com. 259200 IN NS server2.example.com.
example.com. 259200 IN MX 10 server1.example.com.
example.com. 259200 IN MX 20 server2.example.com.
server1.example.com. 259200 IN A 127.0.0.1
server2.example.com. 259200 IN A 127.0.0.2
www.example.com. 259200 IN CNAME server1.example.com.


This format is less canonical, but at least each line is context-free. Now you can proceed to grep the output to your heart’s desire :-)