Dynamic IPs and rDNS

A continual source of complaints by the uneducated is that SORBS is trying to tell people how to run their networks.  Unfortunately there is not much we can say except that they are wrong on so many levels.  Here is some information about why.

First we believe that we don’t want email from networks that can’t follow basic network setup of services.  If you, as a network administrator, cannot be bothered to setup your network in accordance with good/best current practices we can be fairly sure you don’t care about basic network hygiene and we would probably see very legitimate traffic from your site as apposed to the masses of spam and other nasty traffic.

So what does best current practices really mean?

Well first basic setup for a network is getting routed, and if you get that wrong, well you’re not going to get any traffic so that’s not really an issue.

Next you’d give names to everything on your network.  Now this is where the first issue starts.  There are these things called ‘A’ records, ‘MX’ records, and ‘NS’ records (to name the most important few.)

NS records provide the “glue” for DNS (Domain Name System, the service that translates www.yourdomain.example.com into an IP address)  The “glue” tells the system where the authoritive names are for your domain(s) and without it anyone requesting a lookup would not be able to work out where to send the request.

A records provide the name to IP address translation.  Each A record will have a hostname which when combined with the domain name (using NS records) will return IP addresses of computer/server/host/cluster that you want to talk to.  The IP addresses are used for the computers to talk to each other, not the names.

MX records are “Mail eXchanger” records, which means a record which tell your computer where the server is that will receive email for the domain you are trying to email to.

This all seems quite simple, and most people get this right as there are many examples of how to setup your own domain on the internet.  The problem comes with the other records that people ignore such as the ‘PTR’ records (reverse “PoinTeR” records) in most cases PTR records are not required to make things work so people ignore them.  The PTR record though is used by remote machines (such as email servers) to verify who is sending the email and provide a human readable view.  What this means is when a computer has the IP address “1.2.3.4″ (which really means nothing) a mail server when receiving a connection from it will check for a PTR record and if it gets one (eg: mail.example.com) will insert that information into the message so anyone with a filter that says “I want email from example.com servers” will be able to whitelist it.  Seems simple enough so far, however some people also use it to base a complex set of rules and will usually check the PTR records match the A records and visa-versa (to ensure no forgery) and will reject all mail when this fails.  They may also (like AOL) reject all mail from IP addresses that don’t employ PTR records.

Best Current Practices (and the same recommended practice since the early 1990′s) are that every host has an A record and the IP address used in the A record has a matching PTR record.  Of course with later developments of the internet IP address space started to fill up and so you would find that one server might have many A records from differing domains.  RFC1912 was created in 1996 to address common DNS issues and addresses the PTR record from a BCP point of view.  A records do not have to have a matching PTR record but all PTR records MUST have a matching A record (Section 2.1) here is the quote:

Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain. If a host is multi-homed, (more than one IP address) make sure that all IP addresses have a corresponding PTR record (not just the first one). Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all. Also, PTR records must point back to a valid A record, not a alias defined by a CNAME. It is highly recommended that you use some software which automates this checking, or generate your DNS data from a database which automatically creates consistent data.

The PTR issue existing often is the source of support calls to ISPs, and as they want a quite time, they take the lazy option and create PTR records that look like ’1.2.3.4.example.com’ or ’1.2.3.4.dsl.example.com’ and then create a bunch of associated A records so the “forward-reverse’ verification doesn’t fail.  Being the ‘lazy’ option they also make the process as simple as possible, some more advanced admins are familiar with ‘$GENERATE‘ lines some just write scripts to populate the zone files statically.  The ‘$GENERATE‘ lines are not as silly an idea as all think though as they can be overrided.

To use the $GENERATE line you can add the following to a zone file:

$GENERATE 11-254 $ PTR dhcp$.example.com.

This will generate the following records:

11 PTR dhcp11.example.com.

12 PTR dhcp12.example.com.

13 PTR dhcp13.example.com.

…

253 PTR dhcp253.example.com.

254 PTR dhcp254.example.com.

Note: $GENERATE can be used for both PTR and A records so you can also use them to add the A records to match the PTR records.

So were does SORBS come into all this, well if SORBS see records for 65,000 consecutive addresses we feel that the admins of the network can’t be bothered with that part of their network, or that they feel everything in that area are non-consequential hosts (eg: home users that are browsing the Internet – and therefore not running servers.)  The result is that we can block those hosts as they either aren’t or shouldn’t be running email servers.

We believe all hosts on the Internet that are servers should be registered in the Domain Name System (DNS), we believe that for hosts that have multiple services (eg a web server hosting 100′s of domains) the servers’ hostname should be registered with both A and matching PTR records.  However the web services require the A records, but the PTR records are not mandated so should be skipped.  This is best current practices and everyone who follows these practices never run into issues with SORBS.

If you are an administrator that doesn’t follow the best current practices and has problems with SORBS now you know why…

Now why was the $GENERATE information given, well there are some ISPs who wish to set “default”, a set of PTR records that apply to everyone where the customer has not set their own (yet).  For this the $GENERATE records are ideal but the choice of what goes in them causes issues.  SORBS looks at these records and if we see things like ’127.0.0.1.static.example.com’ we know the administrators of the network statically assign these networks out to their customers.  If we see ’127.0.0.1.dsl.example.com’ we conclude that the administrators have assigned generic DSL lines to that address space.  Generic DSL being the majority which is of course the home user with a web browser never even considering to run a mail server, but often getting infected with viruses and trojans that send spam, consequently we block it.

Is this SORBS telling you how to run your network?  Not really you can run your network however you want, what SORBS is telling you is if you want to run mail servers from your network we will not accept mail whilst you look like the majority of users (the majority being home users.)  On the other hand, if you want to run your network conforming to best current practices we will be happy to accept mail from you.

To try and simplify things (and cut down the 27,000+ different patterns in use in 2005), staff at SORBS created a draft RFC for defining the ‘tokens’ used in Generic PTR records and whilst in the process of submission it was suggested that it should be submitted as a standard rather than an RFC.  For this to happen the RFC was submitted to the DNS Operations working group, and the original draft allowed to expire.  Unfortunately there are a lot more important issues that are ahead of the proposed standard and it is going to be some years before it is progressed.