Subject: RE: [Sipping] NAPTR and SRV

From: "Stastny Richard" <[email-masked]>
Date: Fri, 11 Feb 2005 12:58:36 +0100

Jim wrote:
> 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.

No, I did not, but thank you for the exhaustive explanation. 

As far as I know, most providers implement only
the SRV RR, but this may be wrong. So I asked if the additional
usage of NAPTRs is already common practice.

Additionally I asked if these NAPTRs are still using the
format (and will continue to use) "SIP+D2T", or if they
also changed it similar to E2U into "D2T+SIP", or if
plans are existing to do so e.g. for consistency.

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

Yes, I could do so, but many people are not able too. If we want to get
SIP popular also service providers should get some basic training ;-)

It should also be common practice with service providers to offer SIP
"forwarding" similar to mail forwarding, but somebody has to tell them

Regards
Richard

> -----Original Message-----
> From: Jim Reid [mailto:[email-masked]]
> Sent: Friday, February 11, 2005 11:44 AM
> To: Stastny Richard
> Cc: Frank Shearar; [email-masked]
> Subject: Re: [Sipping] NAPTR and SRV
> 
> >>>>> "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.

_______________________________________________
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 13:17:17 +0000

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

    Richard> As far as I know, most providers implement only the SRV
    Richard> RR, but this may be wrong. So I asked if the additional
    Richard> usage of NAPTRs is already common practice.

AFAIK few DNS providers offer anything more than changing or adding A,
MX, SOA, NS, CNAME and PTR record types.

    Richard> Yes, I could do so, but many people are not able too. If
    Richard> we want to get SIP popular also service providers should
    Richard> get some basic training ;-)

Sounds like somebody should write up an I-D. Which WG? This one? ENUM?
DNSOPS? 

    Richard> It should also be common practice with service providers
    Richard> to offer SIP "forwarding" similar to mail forwarding, but
    Richard> somebody has to tell them

I think Darwinism will solve that.

---

From: lconroy <[email-masked]>
Date: Fri, 11 Feb 2005 14:37:51 +0000

Hi Richard, Jim, Frank, folks,
  An RFC is forever. Thus, the syntax specified in RFC3263 will remain, 
including its reference to the obsolete NAPTR definition of RFC2915. 
There is no need for synchronisation with (other) DDDS Applications.

To reinforce Jim's comments::
It all works, and allows flexibility both for service preference and 
load balancing.

This does raise a related issue - Why use a NAPTR to point to a default 
SRV for a home system?

(i) The D2x NAPTR specification allows one to point to non-default SRV 
resources
[e.g. example.com NAPTR SIP+D2U ..... _sip.udp.example.net].
One needs an SRV in _sip._udp.example.com for backwards compatibility 
with "stone-age" clients (i.e. ones that exist), but people's spiffy 
new clients could instead use the SRVs at _sip._udp.example.net.

(ii) Another reason for D2x NAPTRs it to allow you to specify which 
kind of transport you prefer, so that, for example, you might specify a 
lower order value for the SIPS+D2T NAPTR than for the SIP+D2U NAPTR - 
i.e. you prefer to talk SIP over TLS/TCP, but if that's not possible 
then you can talk over UDP.

You need the NAPTRs as a set of SRV records specify the preference for 
servers all of which support the same transport and service. You can't 
do this just with SRVs.
For example, one could do three queries (for _sip._udp.example.com and 
then for _sip._tcp.example.com, then for _tcp._sips.example.com), 
getting back a set of SRVs each time. However, the preference values 
for each RR are NOT comparable between sets - if the _sip._udp SRVs 
have preferences of 20..29, whilst the _sips._tcp SRVs have preferences 
of 10..19, these preferences don't mean a thing outside the context of 
each set - the numbers are "false friends" when doing multiple SRV 
lookups.

So...
For robust service provider set ups where one supports multiple 
transports, multiple servers for each transport, and all of these 
whizzy things, D2x NAPTRs and SRVs are useful.

Note - for historical (read bug) reasons, the DNS cache servers 
provided by many ISPs
        don't provide the additional information section with the SRVs 
in it. Thus, for
        spiffy clients, they may have to make yet another DNS query due 
to the brokenness
        of their ISP's DNS infrastructure.
        Before Jim dives in, yes, one could change one's ISP, but this 
is something that
        people may not even realise is going on.
        Those that DO provide the additional information do not, AFAICT, 
return the IP address
        for the SRV target, so you still need another lookup. Two 
queries is reasonable (NAPTR, A),
        but 3 (NAPTR, SRV, A)?!?

The standard implementation I've seen on SIPish boxes includes 
constructing an SRV query for the destination domain, which would point 
one at the right data in many cases - jim's and isc's are examples of 
this, so it's arguable whether or not these zones benefit from the 
NAPTRs.

For home servers that only support UDP or even TCP and UDP, one has to 
wonder why one would ever bother, unless one also supported SIPS and/or 
SCTP - on a home box?!

With what I assume is your home setup, IMHO the SRV will do, if you can 
apply clue to the Name Service hosting company. Good Luck.

all the best,
   Lawrence

>> records. Which is hardly surprising as it predates RFC2915. Sigh.
---------------------------------------
lawrence conroy    |tel:+44-1794-833666

---

From: Jim Reid <[email-masked]>
Date: Fri, 11 Feb 2005 15:18:20 +0000

>>>>> "lwc" == lconroy  <[email-masked]> writes:

    lwc> Hi Richard, Jim, Frank, folks, An RFC is forever. Thus, the
    lwc> syntax specified in RFC3263 will remain, including its
    lwc> reference to the obsolete NAPTR definition of RFC2915.  There
    lwc> is no need for synchronisation with (other) DDDS
    lwc> Applications.

In that case, DNS-MODA would be happy to publish this BCP. Any
volunteers to write this up? It would be even better if this was an
incentive for some organisations to join DNS-MODA. :-)

---

From: Jim Reid <[email-masked]>
Date: Fri, 11 Feb 2005 15:24:17 +0000

>>>>> "lwc" == lconroy  <[email-masked]> writes:

    lwc> Those that DO provide the additional information do not,
    lwc> AFAICT, return the IP address for the SRV target, so you
    lwc> still need another lookup. Two queries is reasonable (NAPTR,
    lwc> A), but 3 (NAPTR, SRV, A)?!?

This is worst case scenario. However if the resource records are
organised correctly, the replies will have all the relevant RRs in the
additional section. Just one lookup would be needed, as can be seen
from a query for the ISC's NAPTR records. This is just like how MX
lookups generally work. They don't *have* to contain the A or AAAA
records for the target SMTP server. But they usually do.

I suppose this is something our hypothetical BCP could explain too.