dnssrvsrv-record

Using parent domain to query DNS SRV for sub domain

I am writing an application to query the DNS SRV record to find out an internal service for a domain obtained from the email address. Is it correct to do the following.

Is the above approach right? Assuming its not, are there any RFCs or standards that prevents an application from doing it?

Solution

  • Is the above approach right?

    No, it is not. You should not "climb" to the root.

    There is nothing explicitly telling you not to do that in RFCs and you will even find some specifications telling you to climb to the root, see CAA specifications (but they had to be changed over the year because of some unclarity exactly around the part about climbing to the root).

    Most of the time, such climbing creates more problems than solution, and it all come from "finding the administrative boundaries" which looks far more simple than what it is really.

    If we go back to you example, you say, use _service._tcp.test.example.com and then _service._tcp.example.com and then I suppose you stay there, because you "obviously" know that you shouldn't go to _service._tcp.com as next step, because you "know" that example.com and com are not under the same administrative boundaries, so you shouldn't cross that limit.

    Ok, yes, in that specific example (and TLD) things seem simple. But imagine an arbitrary name, let us say www.admin.santé.gouv.fr, how do you know where to stop climbing?

    It is a difficult problem in all generality. Attempts were made to solve it (see IETF DBOUND working group) and failed. You have only basically two venues if you need to pursue: either find delegations (zone cuts) by DNS calls (not all delegations are new administrative boundaries, but a change of administration should mean a delegation; and obviously there is not necessarily a delegation at each dot, so you can not find all of this by just looking at the string, you need to do live DNS queries) OR using Mozilla Public Suffix List, which has a lot of drawbacks.

    This is all basically a rehash of what you can read in "§4. Zone Boundaries are Invisible to Applications" of RFC5507, quoting the core part here:

    The false assumption has lead to an approach called "tree climbing", where a query that does not receive a positive response (either the requested RRSet was missing or the name did not exist) is retried by repeatedly stripping off the leftmost label (climbing towards the root) until the root domain is reached. Sometimes these proposals try to avoid the query for the root or the TLD level, but still this approach has severe drawbacks:

    [..]

    o For reasons similar to those outlined in RFC 1535 [RFC1535], querying for information in a domain outside the control of the intended entity may lead to incorrect results and may also put security at risk. Finding the exact policy boundary is impossible without an explicit marker, which does not exist at present. At best, software can detect zone boundaries (e.g., by looking for SOA Resource Records), but some TLD registries register names starting at the second level (e.g., CO.UK), and there are various other "registry" types at second, third, or other level domains that cannot be identified as such without policy knowledge external to the DNS.

    Note indeed also the example given for MX because a naive view you apply the same algorithm there, but as the RFC says:

    To restate, the zone boundary is purely a boundary that exists in the DNS for administrative purposes, and applications should be careful not to draw unwarranted conclusions from zone boundaries. A different way of stating this is that the DNS does not support inheritance, e.g., an MX RRSet for a TLD will not be valid for any subdomain of that particular TLD.

    There are various examples of people having tried to climb to the root... and creating a lot of problems:

    So, in short, without a solid understanding of DNS, please do not create anything "climbing" to the root. Do note that RFC2782 about SRV gives "Usage Rules" without a case of climbing to the root.

    You are not explaining fully why you are thinking about this. I suggest you have a look at the newest HTTPS/SVCB DNS records (RFCs not published yet, but RR type codepoint assigned by IANA already, and in use by Apple, Cloudflare and Google already), as they may provide similar features set as SRV but may be more relevant for your use case.