Subject: RE: [Sipping] NAPTR and SRV

From: "Stastny Richard" <[email-masked]>
Date: Fri, 11 Feb 2005 10:55:40 +0100

Hi Frank

> SRV: RFC 2782
> NAPTR: RFC 2915
> SIP Locating SIP Services: RFC 3263

Thank you for the quick response, because I am
also interested in the status of this, especially of 
the current status of implementation RFC3263 and 
with the reference to RFC2915.

The background is the following:
I asked my domain hosting provider (domain direct)
to include also the possibility to enter SRV RR in
the zone editing capabilities, because I want to
use my domain name also as SIP URI (e.g. sip:[email-masked])

The response I got back was basically a blank stare:

"Could you explain a little more. What is SIP and SRV? No one here seems
to know what that is."

To provide them with some pointers to RFCs I looked up especially
RFC3263 and found basically the following example

"As an example, consider a client that wishes to resolve
   sip:[email-masked].  The client performs a NAPTR query for that
   domain, and the following NAPTR records are returned:

   ;          order pref flags service      regexp  replacement
      IN NAPTR 50   50  "s"  "SIPS+D2T"     ""  _sips._tcp.example.com.
      IN NAPTR 90   50  "s"  "SIP+D2T"      ""  _sip._tcp.example.com
      IN NAPTR 100  50  "s"  "SIP+D2U"      ""  _sip._udp.example.com.

   This indicates that the server supports TLS over TCP, TCP, and UDP,
   in that order of preference.  Since the client supports TCP and UDP,
   TCP will be used, targeted to a host determined by an SRV lookup of
   _sip._tcp.example.com.  That lookup would return:

   ;;          Priority Weight Port   Target
       IN SRV  0        1      5060   server1.example.com
       IN SRV  0        2      5060   server2.example.com"

But RFC3263 also states:
"However, for backwards compatibility with RFC 2543, a domain
   MUST maintain SRV records for the domain of the original query, even
   if the NAPTR record is in a different domain.  As an example, even
   though the SRV record for TCP is _sip._tcp.school.edu, there MUST
   also be an SRV record at _sip._tcp.example.com."

Now I have two questions, before I go back to
the morons of doamindirect

Q1. Is anybody implementing already the NAPTRs
in this format, or only the SRV RR as defined in RFC2543.
(so do I just request the entry of an SRV in my domain
_sip._tcp.stastny.com. pointing to my sip server, or do
I have to request also the entries of the NAPTRs)

If yes, then:

2. The problem with the NAPTRs is that RFC2915 is obsolete
and replaced by the DDDS series RFC3401-5, basically with
RFC3403. I also wonder if the service field is still
"SIP+D2T" or also turned around to "D2T+SIP" similar
to RFC3761 ENUM "E2U+sip"?

regards
Richard

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Frank Shearar
> Sent: Friday, February 11, 2005 10:24 AM
> To: [email-masked]
> Subject: RE: [Sipping] NAPTR and SRV
> 
> [email-masked] <[email-masked]> wrote:
> 
> > I am a newbie to dns. I need to perform dns query to get the
> > ip address
> > and port of the destination. In res_query, if I give qtype as
> > 1, i am able
> > to get the ip address. But how to do naptr and srv queries to
> > get port no.
> >
> > I referred RFCs relevant to this and none tells about how to
> > form these
> > queries.
> >
> > Can anybody help me in sending query/receiving responses.
> 
> SRV: RFC 2782
> NAPTR: RFC 2915
> SIP Locating SIP Services: RFC 3263
> 
> The first two tell you how to construct the queries; the latter how to
use
> them for SIP.
> 
> As to code, maybe look at the source for the dig program. dig(1), part
of
> bind, comes shipped as standard with at least FreeBSD (and probably
most
> other unix-like OSes). Otherwise, you can find dig in here:
> ftp://ftp.isc.org/isc/bind9/9.3.0/bind-9.3.0.tar.gz
> 
> frank
> 
> 
> *******************************************************************
> This email and attachments (if any) must be swept for viruses before
> opening. Their contents may be confidential or privileged and are
intended
> solely for the named recipient. If you are not the intended recipient
and
> you have received this email in error you must not read or use this
email
> and should notify RNID on: +44 (0) 20 7296 8282.
> 
> 
> 
> RNID, Registered Office 19-23 Featherstone Street, London EC1Y 8SL No.
> 454169 (England, Registered Charity No. 207720)
> 
> ********************************************************************
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jim Reid <[email-masked]>
Date: Fri, 11 Feb 2005 10:43:33 +0000

>>>>> "Richard" == Stastny Richard <[email-masked]> writes:

    Richard> The background is the following: I asked my domain
    Richard> hosting provider (domain direct) to include also the
    Richard> possibility to enter SRV RR in the zone editing
    Richard> capabilities, because I want to use my domain name also
    Richard> as SIP URI (e.g. sip:[email-masked])

    Richard> The response I got back was basically a blank stare:

    Richard> "Could you explain a little more. What is SIP and SRV? No
    Richard> one here seems to know what that is."

So find a service provider who does. Or manage your zone files
yourself.

    Richard> Q1. Is anybody implementing already the NAPTRs in this
    Richard> format, or only the SRV RR as defined in RFC2543.  (so do
    Richard> I just request the entry of an SRV in my domain
    Richard> _sip._tcp.stastny.com. pointing to my sip server, or do I
    Richard> have to request also the entries of the NAPTRs)

Richard, you seem to be confusing NAPTR and SRV resource records. In
summary, the NAPTR records for some domain identifies the order and
preferences for a set of services. The SRV records for those services
-- if they exist! -- identify which server and port number to use.

Although NAPTR and SRV records can be closely related, they are
mutually orthogonal: ie one can be present without the other. The
NAPTR record is saying some name might exist as SRV records. And if
there are multiple NAPTRs, those records can indicate the service
preferences: ie use TCP before UDP or whatever. The SRV records for
those NAPTRs identify the host and port number providing the service
and (optionally) load balancing and priorising of the server(s) that
get used. If an application has a priori knowledge that SRV records
exist for some name, it can of course just go ahead and look them
up. However this means that the application may be ignoring info that
was in any NAPTR records for order and precedence handling.

So if the resource records are organised according to RFC 263 all is
well. The client looks up NAPTR records and gets a response that
should have the corresponding SRV records in the Additional Section of
the reply. Do a NAPTR lookup for rfc1035.com or isc.org to see how
this works.

My guess is RFC3263 says "a domain MUST maintain SRV records for the
domain of the original query" because there could be legacy SIP
applications that only follow RFC2543. This has no mention of NAPTR
records. Which is hardly surprising as it predates RFC2915. Sigh.