David A. Bandel
Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.
The contents of this site are original material (copyleft) from the deranged mind of David A. Bandel -- all rights (and lefts) reserved. If you are as of unsound mind as I am and actually want to quote anything here, be my guest, but I would appreciate attribution (a link back to the original text would be even better). Thanx for your support.
Just three little letters, and yet, without them, we'd never get any e-mail. OK, so that might not be such a bad thing for some of you, but most of us have really become dependent on those bytes coming from and going to our in- and out- boxes. Few things have been more convenient -- or lately, more abused (but more on that in another article).
I want to note that this article is not a DNS How-To, lots of those can be found. Just some of my observations on DNS here in Panama.
Now back to DNS. This oft-overlooked service is vital to the functioning of the Internet. Without it, computers have no way of knowing which other computer to connect to for anything -- mail, surfing the web, chatting, nothing. We humans remember names: google.com, slashdot.org, freshmeat.net, etc. They may be easy or hard to remember, names with or without meanings, whatever, but are a whole lot easier than trying to remember an IP address (like 188.8.131.52, one of google's addresses). These names also don't change (that last number used to be .99 in google's IP, and may or may not still work).
Just as we use a telephone directory to look up a phone number for someone or some business, computers use DNS as their directory to look up the IP address that corresponds to the hostname of a computer. Most network and system admins know about and can deal with DNS, or at least configure their systems to point to one that works. I find few admins however, that really understand how they work, and they really should. I know a number that even understand how to set up zones and create a resource record (RR), but beyond that, they are lost. And there, they only understand about a forward zone, such as the one for pananix.com that provides name to IP lookups.
Unfortunately, in today's world, we need many more admins that understand not only forward lookups, but what are called reverse lookups -- IP to name lookups. With the unabated rise of spam (a crime I consider a capital offense), many folks, like myself, who run mail servers, refuse mail if the reverse DNS doesn't exist for an IP. Now I'm not talking about a match (although that's nice). I'm talking about reverse DNS (rDNS) simply existing. I have a mail server with about 30 domains on it. Performing an rDNS lookup (using "dig", the command is: dig -x 184.108.40.206) you will get a name. If you perform a forward lookup on the name, you "should" get a match, although it may not be the name you initially started with. That is, you might lookup mail.pancall.com, get the IP, reverse that IP, get mail.pananix.com, lookup up mail.pananix.com, and get a match between the IP for mail.pancall.com and the name mail.pananix.com. You may only get one name that is reversed (I'm guilty here), although all names really should be reversed (RFC-1912 and others).
If you didn't quite understand the last para, don't worry about it (unless you're a DNS admin). So if I reject mail from you with a note saying your zone isn't reversed, then you know where the problem lies, complain to your provider. Unfortunately, this is true for any number of assigned IP blocks. Cable & Wireless Panama is a prime example. They assign static IPs to businesses. I have a number of those businesses who are my customers with mail servers I set up for them. They cannot send me e-mail. And calls to C&W to reverse the zone are met with complete silence.
Part of the problem is, I suspect, the fact that the majority of so-called admins here in Panama have no clue of anything beyond their little world of MicroSoft Windows. The primary DNS server for C&W is on a SUN system running Solaris. I would bet my bottom dollar it is also running X Windows, as I know few competent command line (CLI) admins here. They either sit down and log in and use a GUI interface to manually edit DNS entries, or use an interface like Webmin to provide a line by line GUI interface to the zone files. Either way, they will be putting in only line at a time, and it will take some time to enter an entire zone (not counting correcting all the errors) manually. At least if they do it IP by IP.
The shame of it is, they are running BIND 9.2.3rc1 or higher (based on a quick scan of their system). Since they allocate zones based on use (static for business, dynamic for residences), it would be extremely fast and easy to reverse an entire zone. Only one line is required. BIND (Berkeley Internet Nameserver Daemon -- the Internet standard) provides some very nice macros to do just this. Here is the one line that reverses 113 addresses in my BIND 9 server (one other line reverses .128-.255):
$GENERATE 14-127 $ PTR shared-$.pananix.com.
I will note that $GENERATE will also work on forward zones for A RRs, so creating a forward and reverse zone that match is less than 5 minutes work really.
The zone for pananix.com is "properly" reversed using guidelines proposed in the DRAFT generic naming schemes document (http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt) as part of the SPAM and Open Relay Blocking System (please feel free to 'dig' to verify these entries). All ISPs should adopt naming schemes based on documents like these, but as I said, some ISPs don't even bother creating rDNS entries at all. I will continue to pick on C&W because their laziness is inexcusable for a large ISP. I am not even "assigned" the IP block in question (it still belongs to my provider), just delegated reverse zone authority. I just don't trust others with something as important as DNS is, so I insist on doing it myself. Customers should insist it be done properly in accordance with the latest "best practices" as proposed by the IETF (Internet Engineering Task Force). Are all my zones 100% compliant? No. Do I understand the implications of deviating from best practice? Yes. But feel free to pick nits if you want to.
I hope you've noticed that while DNS provides directions to any network-connected host, I've focused almost solely on e-mail. That's because SMTP (e-mail) depends very heavily on DNS in a way no other protocol does. So much so, in fact, that most SMTP servers should have DNS running on the system with them to cache entries and speed up transactions.
As of this writing, the BIND macros I discussed above only exist for the IPv4 address space. But that is the predominant space in use today. I'm hoping the BIND authors will address a way to reverse the immense /64 address blocks that IPv6 uses. As it stands, the PTR RRs for IPv6 are a real pain in the wrists. But I expect that will happen. Until then, IPv6 servers should also be reversed, particularly mail servers.
If you know of any DNS admins who are not familiar with the RFCs and current practices, encourage them to come up to speed. Lack of proper DNS records hurts us all. Businesses can little afford to deal with ISPs who are not knowledgeable in networking basics (and DNS certainly qualifies here) or too lazy to implement little things like rDNS. Unfortunately, often there is little choice in ISP.
others subjects based on requestsDNS - yes!
Feedback count: 0
Comments are closed for this story.