SRV Request to DNS

[Mark Andrews]

To answer the question.  What you do when given a name and a port
is protocol specific.  Read the protocol specification.  Note if
the port is the well known port for the protocol then it may be
ignored.

If the protocol does not specify most developers will just implement
the protocol over that port to the specified host taking into account
well known ports if needed.

To used SRV with a protocol you need a specification that says to
do so.  Using SRV without such a specification results in undefined
behaviour.

This really isn't a DNS question.  The DNS is just the database
that stores the values that are being looked up.

Mark


In message <d5ff3ef51b504cca9d832b056043d18f at mxph4chrw.fgremc.it>, "Darcy Kevin
 (FCA)" writes:
> 
> Harshith,
> I think you need to understand the proportionality here: the
> *vast*majority* of the time, the client already knows the port (because
> ports tend to be pre-assigned for specific services), and only needs to
> resolve the FQDN to one or more address records (A and/or AAAA records),
> in order to make a connection. This isn't really a burden, or complicated
> logic in the client software, since it can just call a generic hostname
> lookup function (e.g. the traditional gethostbyname() or the more modern
> getaddrinfo()). It's not like every application programmer needs to deal
> with parsing packet contents, handling retries, dealing with label
> compression, etc. This is all handled in the library routine.
>
> Only in a small minority of cases do clients go through the whole NAPTR
> or SRV process. Some of the main scenarios for that include:
>
> *         Microsoft Active Directory. The clients use SRV records as part
> of the so-called "dc locator" process to find a domain controller that
> provides a specific service
>
> *         Certain IM clients (like Lync) use SRV records to find SIP
> services
>
> *         SIP telephony clients use NAPTR records
>
> Note that SMTP clients use MX records rather than SRV records. MX records
> can be considered the simpler, mail-specific precursor to SRV records.
> Theoretically, SMTP _could_ be switched over to use SRV records, but the
> use of MX is so ingrained that it's probably not worth the (massive)
> effort.
>
> If you look at nameserver query statistics, you'll see that the volume of
> SRV and/or NAPTR queries on a typical nameserver/resolver is a miniscule
> fraction of the A/AAAA traffic. Where MX-record traffic falls between
> those extremes, will depend a lot on whether the nameserver/resolver is
> internal or external, whether the particular domain is heavily used for
> mail, etc.
>
>
>
>                                             - Kevin
>
> From: bind-users-bounces at lists.isc.org
> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Chris Buxton
> Sent: Tuesday, October 13, 2015 7:58 AM
> To: Harshith Mulky
> Cc: BIND Users
> Subject: Re: SRV Request to DNS
>
> On Oct 5, 2015, at 11:51 PM, Harshith Mulky
> <harshith.mulky at outlook.com<mailto:harshith.mulky at outlook.com>> wrote:
> Let us say we are having a FQDN and we need to Resolve it. It goes
> through the procedure of determining the IP and Port using NAPTR/SRV/A
> query mechanisms
>
> The question I have is if I have a FQDN with a Port Number already
> determined, will it go through the Procedure of NAPTR/SRV/A query (or)
> simply do a A query (or) Is this left to the client to apply the Logic?
>
> The client must supply the logic. DNS is conceptually a simple database
> service - ask a question, get an answer. The logic of using NAPTR
> records, SRV records, A records, AAAA records, and CNAME records is
> mostly handled by the client. (CNAME and DNAME records are the primary
> exception, triggering extra processing on the recursive name server.)
>
> Chris
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org