DNS Problem with NAPTR

[JensLantermann]

Hi everybody,

we have implemented the SRV Records,

_sip._tcp.domain.com

_sip._udp.domain.com

_sips._tcp.domain.com

And these entrys are working fine.

But after a long testing I can see that there is a needed NAPTR at domain.com,

and because of this the dns resolution fails.

What are the right parameters for setting our three video SRV's also at the NAPTR?

Thanks!

[Patrick Sparkman]

Hello Jens -

Can you tell us what endpoints you are using, that is requiring the NAPTR records?

Are there other SRV records in place along side the ones you noted above?

We use the same SRV records as you above and everything we use as well as others outside of our network works just fine.

[JensLantermann]

Hi Patrick,

I have done the testing from another VCS Expressway. My testing was for verifing the reachability from outside. I'm coming from "mydomain.com" and tries to reach the "domain.com".

The company with "domain.com" has implemented some services, who needs a DNS NAPTR entry. Now my call starts at the expressway "mydomain.com". The first thing the expressway is asking for at the DNS-Server is a NAPTR of "domain.com".

So we get the NAPTR of the another service and the call fails. There is no try of resolving the SRV-Records.

Our solution now is implementing some more NAPTR Records.

domain.com.  IN  NAPTR  50  10  "S"  "SIPS+D2T"  ""  _sips._tcp.domain.com.
domain.com.  IN  NAPTR  51 10  "S"  "SIP+D2T "  ""  _sip._tcp.domain.com.
domain.com.  IN  NAPTR  52  10  "S"  "SIP+D2TU"  ""  _sip._udp.domain.com.

Actually it is working, but are these the correct settings?

Are there some side effects at these configuration?

[Patrick Sparkman]

Do you have any SRV records already that match those of your video records?  If they don't match, you should be fine without the NAPTR records, as each device will only match what they can support.

As far as verifying your NAPTR records, I wouldn't really know, as our domain only contains our video SRV records, so there is no other records to interfere with.  What other records do you already have in place for your domain?

[JensLantermann]

Hi Patrick,

the external DNS Server has the following SRV Record.

_sip._tcp.domain.com

_sip._udp.domain.com

_sips._tcp.domain.com

and they are correctly matching.

Only the NAPTR request of the VCS, to resolv "domain.com", interferes the communication.

This entry is needed by another application.

And because of this we must enter the additional NAPTR Records.

domain.com.  IN  NAPTR  50  10  "S"  "SIPS+D2T"  ""  _sips._tcp.domain.com.
domain.com.  IN  NAPTR  51 10  "S"  "SIP+D2T "  ""  _sip._tcp.domain.com.
domain.com.  IN  NAPTR  52  10  "S"  "SIP+D2TU"  ""  _sip._udp.domain.com.

Now the solution works.

[Patrick Sparkman]

The last line in your post "Now the solution works".  Does that mean you've already added the NAPTR records?  From what I can see, they look okay, though we don't have them in our DNS, just the SRV records.

[JensLantermann]

Yes you are right, we have added them and everything looks good.

Normally (my last 20-30 customers) do also have only the SRV entrys and everything is working.

But I think if you have one NAPTR who is machting to the video domain, you must also add the VCS SRV records to the NAPTR.

Thanks for your support.

See you next time.

[Chris Swinney · Accepted solution]

Hi Jens/Patrick/All,

I have just come across the same issue. We need to insert DNS records in a root zone to point to a SIP service (VCS-E) for various Universities. However, these Universities already have a single NAPTR record in their zone, which relates to an Eduroam wireless service. A lookup on a non modified domain via a VCS looks like this:

Query type     Name                 TTL     Class     Type     Response
A             university.ac.uk.     2676     IN         A         128.128.128.128
NAPTR         university.ac.uk.     38919     IN         NAPTR     100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.roaming.ja.net.

A modified zone with standard SRVs added looks like this:

Query type     Name                             TTL     Class     Type     Response
A             university.ac.uk.                 2676     IN         A         128.128.128.128
NAPTR         university.ac.uk.                 38919     IN         NAPTR     100 10 "s" "x-eduroam:radius.tls" "" _radsec._tcp.roaming.ja.net.
SRV         _sips._tcp.university.ac.uk.     3600     IN         SRV     0 100 5061 vcse.ourdomain.ac.uk.
SRV         _sip._tcp.university.ac.uk.     3600     IN         SRV     0 100 5060 vcse.ourdomain.ac.uk.
SRV         _sip._udp.university.ac.uk.     3600     IN         SRV     0 100 5060 vcse.ourdomain.ac.uk.

However, a TCPdump from the VCS-E taken when you attempt to lookup a SIP address results in initially an NAPTR query (as Jens has indicated above). The resultant NAPTR set response does NOT included any SIP services (only that realting to the "x-eduroam:radius.tls" service), however, the VCS-E dose NOT them go on to query for SRV records, it just stops.

I'm not sure if this is a standards DNS action or if the VCS should realise that there are no SIP services defined in the DNS response and continue searching for SRVs. If there are no NAPTR records defined in the zone, the VCS will receive and empty set (i.,e. 0 Answers), and therefore the VCS will continue to lookup SRV records.

The VCS Administration guide does not mention that this is the default action. I thought this worthy or a separate thread, which I have posted here.

I too will have to ask to insert NAPTR records into these zones in order to overcome this failing, however, the last thing I want to do is create an issue with the pre-existing service.

Cheers

Chris