Building a DUL on demand

A DUL or a Dial-Up-List is a DNS list that gives an A record (usually in the 127.0.0.0/24 range) for IPs that’s dynamically assigned, such as dial-up users, or various DSL services. Basically, any technology where an IP is not assigned to a specific person (3G, iBurst, ADSL, sentech, dial-ups).

What the question is now, is whether it’s possible to build such a DUL based on the information provided in whois. Initially it seems one could possibly use the “inetnum” and “status” information that gets returned, eg:

$ whois 41.240.163.193 | grep -E '^(inetnum|status):'
inetnum:        41.240.0.0 - 41.240.255.255
status:         ASSIGNED PA
$ whois 196.35.70.139 | grep -E '^(inetnum|status):'
inetnum:      196.34.0.0 - 196.35.255.255
status:       ALLOCATED PA
$ whois 196.25.1.1 | grep -E '^(inetnum|status):'
inetnum:      196.25.1.0 - 196.25.1.255
status:       ASSIGNED PA

The first of those IPs is a dynamic IP, the second is a static IP, and behove and behold, thank you very much SAIX – the last is a static IP.

So if it was (someone may still point out something I’m not aware of) possible – what would be the purpose of such a list? Well, to put it simply, dial-up users should be relaying mail via their ISPs mail server, so I want to use such a list to block dial-up users (or users otherwise in a dynamic range) from delivering mail directly to me.

The basic procedure would be something like:

  • Get an IP we’d like to know whether it should be in the DUL or not.
  • Check in local database whether it’s known (ie, in a previously looked up range), if so, either respond with an A record, or NXDOMAIN, else:
  • Perform a whois lookup on the IP.
  • Store the block locally (along with lookup time) and respond with the appropriate A record, or NXDOMAIN.
  • Periodically re-check the blocks to ensure that our data stays up to date – or alternatively just expire old data from the local database (say after a 30 day period).

There are, however, some pitfalls. First and foremost is the insane amount of data. In the worst case (only considering IPv4) we have 232 potential blocks (or if we could store the information regarding a single IP in 1 byte, 4GB worth of information). Now, for each IP we want to at least store lookup_time (32-bit int) and type – 1 bit. This gives us 33 bits, thus if we can agree on a different reference point for time we can get away with 16GB worth of data. This is still too much, but considering that the majority of blocks that we look up will probably be /24 or bigger blocks I reason we can bargain on approximately 16 million records, however, in this case we need a starting IP (4 bytes), ending IP (another 4) a timestamp (4) and a status (and to make provision for more than just dul/not dul i’ll concede a byte) we end up with 13 bytes per record, or about 208MB worth of data. Obviously additional indexing overhead and some other stuff but significantly more manageable.

Then there are change-over periods, where a block that was previously assigned to servers/clients is now allocated dynamically.

We probably want to do this on-the-fly inside of a DNS server – I’m not aware of any with the functionality.

And the final question – how do you even (reliably) determine whether an IP block is assigned or allocated?

Comments are closed.