Anders Brownworth

Technology and Disruption

Tutorial: SIP using NAPTR and SRV DNS Records

SIP can be run, for example, over UDP, TCP or TCP with TLS (SSL) encryption however standard "A" DNS record lookups won't tell you anything about which of these protocols to use. NAPTR records are commonly used with SIP in conjunction with SRV records to discover what types of service are available for a name, (such as SIP, email or web) what name to use for an SRV lookup and (using the SRV record) what port and "A" records to use to find the IP for the service. That might come off sounding somewhat complicated so lets take a look at the entire process through an example.

Lets consider a call to Given only this address though, we don't know what IP address, port or protocol to send this call to. We don't even know if supports SIP or some other VoIP protocol like H.323 or IAX2. I'm implying that we're interested in placing a call to this URL but if no VoIP service is supported, we could just as easily fall back to emailing this user instead. To find out, we start with a NAPTR record lookup for the domain we were given:

# host -t NAPTR NAPTR 10 100 "S" "SIP+D2U" "" NAPTR 20 100 "S" "SIP+D2T" "" NAPTR 30 100 "S" "E2U+email" "!^.*$!!i"

Here we find that gives us three ways to contact, the first of which is "SIP+D2U" which would imply SIP over UDP at But first, a bit about all the fields we have here.

In the first line of our result in the example above, is the name we looked up and NAPTR is obviously the type of record. The 10 refers to the preference for the record. The lower number is always tried first. 100 is the order and is only important if the preference numbers are the same.

The "flag" field, in this case "S", is next. There are currently four possible flags: "S" which denotes that an SRV lookup is to be performed on the output of this NAPTR record. "A" means the result should be lookedup as an "A", "AAAA" or "A6" record. A "U" means that the NAPTR result is an absolute URI that the application should process. A "P" would signify a "non-terminal" rule where additional NAPTR lookups would be necessary. It is application specific and can be mutated by regular expressions. (discussed below)

Next we have the "services" field, "SIP+D2U", "SIP+D2T" and "E2U+email" in the example above. "SIP+D2U" is SIP over UDP, "SIP+D2T" is SIP over TCP and (you guessed it) "E2U+email" stands for email. This is the application specific service optios we have to reach

It might be hard to notice the next field, "", because there is nothing there, but this is the "regular expression" field. The regular expression is used to mutate the original request (in this case "") into something new. We're not using it here but you could use this to substitute the entire name or parts of the name used in the original query. (NOTE: These are NOT cumulative. You would never use a regular expression on the output of a NAPTR lookup, only on the original query.)

The last item we have is the "replacement". In the first result from our example above, we have "". Regular expressions and replacements are mutually exclusive. If you have one, you shouldn't have the other. The replacement is used as the "result" of the NAPTR lookup instead of mutating the original request as the regular expression in the paragraph above.

That's all of our fields. So because we have the "S" designation in the "flag" field, our next step is to find the SRV record for the replacement "".

# host -t SRV SRV 5 100 5060 SRV 10 100 5060

We get two answers here so first we'll try because it has the lower of the two priorities. (priority 5 before priority 10. 100 is the weight which is used to differentiate between records of the same priority.) Next we do an "A" record lookup to find the IP of the server to use to send our SIP INVITE.

# host has address

So in this example, our top preference would be to send a SIP INVITE via UDP to port 5060 on Failing that, we would look up the IP for the other SRV response ( and hit that via UDP on port 5060 as well. Failing all of that, we would go back to the next response we got via the original NAPTR lookup and do an SRV lookup on and presumably try a TCP connection to some other server and port combination. And lastly, failing all of that, the last response from the NAPTR lookup has us sending an email to

Of course this usually isn't done on the command line, but by an application. It is handy, however, to see how you can mimic the requests a VoIP application is going to make for illustration and troubleshooting purposes.

Not all clients will be able to speak all protocols so you should try to supply some alternate methods of contact in your NAPTR response rather than just one protocol in practical implementations. This could become particularly interesting in a fully IP world when, for example, my "contact info" is The NAPTR record would return several ways for me to be contacted perhaps via VoIP, an IM option and lastly an email option. Remember, VoIP calls aren't restricted to numbers only, so as long as a client supports it, NAPTR allows for your email address to also be your VoIP "number".

While most major DNS server packages out there today support NAPTR and SRV records natively, some do not. In the case of djbdns's tinydns authoritative nameserver, there is a patch for NAPTR support but you can also describe NAPTR records in the generic record format. There is a djbdns NAPTR record builder that creates NAPTR records in the generic syntax for use with an unpatched djbdns tinydns server.

Note: Be aware that some applications (such as OpenSER / OpenSIPS) prepend the protocol information (_sip._tcp or _sip._udp) to names automatically before doing the SRV lookups. Check your nameserver log to see what clients are asking for.

Comments (19)

conor mckinvan from ancaster ontario canada

hi and thanx for all the information it really helped on my projects

Bernard Ku from Austin, TX

Are there any limit of NAPTR records allowed per each E164 numbers?

Too many NAPTR records would result in truncated responses and repeated queries over TCP transport. That has a severe impact on the DNS server load and the latency of those ENUM queries.

Anders from RTP

There isn't a limit on the number of ENUM records though of course there would be a practical limit at some point. I see two issues, one with the size of the response which would generally be split across multiple packets or migrate to tcp as you suggest, and the other with multiple requests when a NAPTR record doesn't return a terminal state so additional lookups are necessary. Non-terminal NAPTR records aren't common yet so I don't think that is much of an issue. The size of your records is another matter though so I'd test that out.

What is your application that you need so many responses to one query?

A side note: djbdns doesn't use TCP.

Luis from Portugal

You say that the "Regular expressions and replacements are mutually exclusive.". But in the example above " NAPTR 30 100 "S" "E2U+email" "!^.*$!!i"" you have both. am I right? I've read for several times the rfc and I still can't understand the difference between both replacement and regular expression.

Anders from NY

Yes, the example gives values for both so that wouldn't be what you would want to do. Regular expression rules aren't very common at all. Theoretically they are very powerful but doing "recursive" DNS calls can be expensive in both network and time so they haven't caught on much. Whats your application? Is it something you think that needs regular expression rewriting? Or will a "standard" terminal rule work for you?

Ashok Pancharya from Hyderabad, India

Really helpful tutorial for me. Thanks a lot Anders. I am setting up a OpenSIPS server and must know what an NAPTR DNS record is. I did add SRV records in DNS of my domain but did not add any NAPTR record. I am going add the NAPTR records now.

Debdoot from Kolkata/West bengal/India

Nicely explained.
1.Can u provide a DNS call flow?
2. A sample trace or a wireshark trace for a better understaing of scenario.
3. Explain the Connectivity of DNS server to root DNS.

Kishor from Toronto

Best explanation i found on google. Thanks alot.

Tony from Paris

Is there a possibility of creating different NAPTR records on a server?

In your example, can a completely different result be turned for and routing them to different SIP servers for example?

Thanks for your help, great article!!!

Anders from Cambridge, MA

Unfortunately you can't return something different based on something outside of the name - which the @ is - so what you are trying to do isn't possible. It is a limitation of the DNS system. You could, however, send all names to a director service that sends the request on to different endpoints based on the number called. Kamailio SIP Server would be a good tool to do that.

Attel from India

Thank you very much for the article. It clearly explains the NAPTR->SRV->DNS->A resolution.

Anais from Madrid, Spain

Hi Anders, great article!

I have a question. I'm trying to apply the configuration you explained, but I don't have FQDN for the SIP Servers I'm trying to use. I only have IP Addresses. Do you have another article explaining how to add A entries or how to use NAPTR with A query instead of SRV? Thanks in advance!

Anders from Cambridge, MA

@Anais: Adding A records is done using likes in the data file that look like this:

Mahesh Shah from Texas

Excellent article. Thanks.

William from Colombia

On which cases the second priority/order on list is used?

-when the first one does not respond?
-round robin?


Anders from Cambridge, MA

@William: The priority is effectively only a hint to the application. The RFCs describe what _should_ happen but ultimately it is up to the clients to decide what to do. (and why to attempt anything but the highest ranked item) Reasons a client might not pick the top-most item would be inability to support the protocol, for example. There is no guarantee that a client will act correctly.

Godfrey from Singapore

Great explanation. Thank you.

Rupak from india

Its Really Simple and Easy to Understand the Different Type of DNS Query.

Thanks Anders!!!

Vipin from India

Thanks a lot for the detailed explanation.

Leave a Comment

Location: (city / state / country)
Email: (not published / no spam)

No HTML is allowed. Cookies must be enabled to post. Your comment will appear on this page after a moderator OKs it. Offensive content will not be published.

Click the banana to submit your comment.

To create links in comments:
[link:] becomes
[link:|] becomes
Notice there is no rel="nofollow" in these hrefs. Links in comments will carry page rank from this site so only link to things worthy of people's attention.