ENUM

ENUM (E.164 Number Mapping) is a protocol that maps E.164 telephone numbers to network services using DNS. Infobip exposes an ENUM interface for HLR (Home Location Register) lookups, allowing you to query mobile number routing information using standard DNS query packets.

An HLR lookup queries the mobile network subscriber database to determine the state of a number. Use it to check whether a number is valid and active, and which operator serves it, including after number portability. It also returns the routing identifiers (IMSI, MSC) needed to reason about deliverability, all without sending a message to the subscriber. A lookup reflects near real-time network state, so it can reveal a ported or roaming number that a static prefix check misses.

ENUM is one of four Number Lookup access methods. Use it when you already run DNS infrastructure, or when you need low-latency, high-volume lookups. To compare the methods, see Number Lookup access methods.

Connectivity

To enable connectivity between the Infobip ENUM interface and your system, raise a support ticket with the list of source IP addresses to be safelisted. Infobip then safelists them, assigns a dedicated UDP port on the ENUM server for your connection, and provides the server address and port. For the supported IP formats, see IP safelisting in Security best practices.

ENUM queries are standard DNS NAPTR queries sent over UDP to the Infobip ENUM server. Use the server address and port provided during setup (the @x.x.x.x in the examples on this page stands in for the ENUM server IP).

Because UDP has no handshake or acknowledgement, a lost query or response yields no answer. Set a query timeout on your client and treat a missing response as a failed lookup to retry.

ENUM query packet

Each ENUM query must fulfill specific requirements. QTYPE must be NAPTR. Additional restrictions apply to the other ENUM query parameters, and the ENUM server rejects any query that does not comply with them.

HEADER section of ENUM query [#header-section-of-enum-query-enum-query-packet]

• QR bit must be set to 0 representing DNS query
• Opcode must be 0 representing a standard DNS query
• Only one ENUM query per DNS packet is possible, so QDCOUNT must be 1
• ANCOUNT, NSCOUNT, and ARCOUNT must be 0

QUESTION section [#question-section-enum-query-packet]

The QUESTION section must meet the following requirements:

• QNAME must be built from the E.164 number using the ENUM "well-known rule" (RFC 3761), then appended with the Infobip ENUM root. See the construction steps that follow.
• QTYPE must be NAPTR as specified in RFC 2915.
• QCLASS can be any class defined in RFC 1035. The standard for this service is the internet class (IN).

To construct the QNAME:

1. Remove the leading + and any non-digit characters, leaving only digits (+385915017345 becomes 385915017345).
2. Reverse the order of the digits (385915017345 becomes 543710519583).
3. Separate every digit with a dot (5.4.3.7.1.0.5.1.9.5.8.3).
4. Append the Infobip ENUM root, giving 5.4.3.7.1.0.5.1.9.5.8.3.infobip.net.

Example query with dig [#example-query-with-dig-enum-query-packet]

In this example, x.x.x.x represents the IP address of the ENUM server. The queried number is the same one used in the successful response example later on this page. The example numbers are illustrative only and are not guaranteed to resolve.

ENUM server responses

ENUM server response format is compliant with RFC 1035 and RFC 3761. RRs returned contain only NAPTR RDATA. In every response:

• The QR bit is set to 1, representing a DNS response.
• RCODE is NOERROR when the ENUM request is processed successfully and a NAPTR answer is returned. Otherwise, RCODE is one of the values in ENUM error responses.
• The QUESTION section is the same as in the ENUM query the response answers.

ENUM error responses

When the ENUM server cannot complete a query, it returns an error response: the QR bit is set to 1, and RCODE is never zero.

If the ENUM server cannot parse the DNS header, or an unexpected error occurs while it processes the request, it discards the packet. It sends no response at all. This is not an RCODE value: the client receives nothing and must rely on its query timeout to detect the failure.

For all other failures, the server returns one of the following RCODE values.

ENUM responses: successful HLR query

When the ENUM query is successfully processed and the HLR query succeeds, the ENUM server sends a response containing the Answer section. The Answer section contains the HLR query result in the RR for which RDATA type is NAPTR.

RR format [#rr-format-enum-responses-successful-hlr-query]

The following table describes the fields of the resource record.

NAPTR RDATA values [#naptr-rdata-values-enum-responses-successful-hlr-query]

The following table describes the NAPTR RDATA values.

The regular expression carries the lookup result as key=value pairs. The response can contain the basic fields in the following table. It can also contain MCC/MNC, portability, and roaming fields, depending on your configuration and on the lookup response.

Example: successful HLR query [#example-successful-hlr-query-enum-responses-successful-hlr-query]

Example: ENUM success with an HLR error in the payload [#example-enum-success-with-an-hlr-error-in-the-payload-enum-responses-successful-hlr-query]

The following response differs from the RCODE errors described earlier. The ENUM query itself succeeded (status: NOERROR, Answer section present), but the payload carries a non-zero HLR status= value.

Usage notes

• Data freshness: An HLR lookup reflects near real-time network state (active, roaming, serving operator). The 24-hour TTL (86400 seconds) on the response RR does not indicate the freshness of the data. Volatile fields such as roaming and active status are point-in-time and can change after the lookup.
• Cost: HLR lookups carry charges. Pricing is available from your account manager.
• Data sensitivity: Results contain sensitive subscriber and routing identifiers (IMSI, HLR/MSC addresses); the MSC value can be truncated, depending on your connection configuration. Regional regulation may restrict the availability or permitted use of HLR data. For example, some markets restrict HLR access or use a mobile number portability database instead.

Troubleshooting

The following table maps the most common failure responses to their first checks.