Delegating ENUM Resolution Resonsibility

One of the biggest challenges with respect to getting ENUM deployed is politics. Everyone wants to control the numbering plan because they either see money in owning the numbering, they do not want to be liable for service outages due to reliance on some other entity, they fear a loss of control over numbers they control, or something other. In any case, it has been very difficult to move the world to ENUM. Well, I’m here to ask the question, “Why worry about it?”

Dialed Digits is an ENUM service provider. It’s one of many ENUM service providers around the world. One can query Dialed Digits starting at the room of the ENUM tree at enum.dialeddigits.com. Dialed Digits can delegate a portion of the ENUM tree management to another organization for management, too. This can be done by simply inserting NS records into DNS like this under enum.dialeddigits.com:

$ORIGIN enum.dialeddigits.com
4.4 IN NS ns1.packetizer.net.

This DNS record basically says that all of the digits for the UK can be queried via ns1.packetizer.net. (Please note that record is entirely fictitious. Packetizer does not manage the phone numbers for the UK.) So, if I were trying to contact the web team for Buckingham Palace in London at +442079304832, then a query would be sent for 2.3.8.4.0.3.9.7.0.2.4.4.enum.dialeddigits.com. Seeing that +44 is handled by ns1.packetizer.net, a query would be directed to that server, but still looking for 2.3.8.4.0.3.9.7.0.2.4.4.enum.dialeddigits.com. However, what if BT is the owner and manager of those phone numbers? It probably is. Further, I’m quite certain that BT is going to want to manage its numbers the BT domain name, perhaps at enum.bt.co.uk.

So, how do we tell the ENUM resolution engines to go look in an entirely different domain? Here’s my proposal. We should use NAPTR records and introduce a new flag “x” that signals that responsibility for queries have been “transferred” to the specified domain (or sub-domain).

For example, under enum.dialeddigits.com we might have a record that looks like this:

$ORIGIN enum.dialeddigits.com
*.4.4 IN NAPTR 100 10 "x" "" "" enum.bt.co.uk.

So, when a phone number like +442079304832 is resolved, an answer will come back with an NAPTR record that effectively says “go ask again over at enum.bt.co.uk”. And, so the query is re-issued under the specified domain.

What this allows service providers to do is, through DNS and ENUM procedures, to define who the authority is for a given any given digit string and to delegate management to them. There is no need to rely in a central e164.arpa. There would be a need to establish peering relationships, but this approach would actually allow one to rely on any number of companies to provide that peering management.

Imagine if Dialed Digits were the “fallback” service for AT&T. Perhaps AT&T might manage ENUM services for all of its own numbers and might insert “transfer” NAPTR records for some numbers owned by service provides with whom the company has a direct peering relationship. But, for all other digits, it might rely on Dialed Digits to establish those peering relationships and provide the appropriate NAPTR records (either answers to queries or further “transfer” records).

UPDATE: I was exchanging email with Patrik Fältström on this topic. He suggested that, rather than introduce a new NAPTR record, just use DNAME records. That's really a far simpler way of delegating. So, an ENUM provider might have a DNS entry that looks like this:

$ORIGIN enum.dialeddigits.com
4.4 IN DNAME 4.4.enum.bt.co.uk.

This would mean that any query for +44 numbers would be directed to BT's ENUM tree at 4.4.enum.bt.co.uk, if such an address existed.