Use of SRV Records to advertise applications
Nick Piggott (RadioDNS)
We were recently contacted by Patrik Fältström, one of the authors of
the ENUM specification that we refer to in the RadioDNS specification
as an example of mapping existing "analogue" systems into the domain
name structure.
Patrik commented on the use of SRV records to advertise applications,
and asked why other Domain Name Record types such as NAPTR and URI
were not supported.
The mention of SRV records in the core specification is partly
prescriptive and partly demonstrative. As each *application* defines
the naming and structure of the SRV record, it's conceivable that we
could amend the core specification to support any Domain Name Record
type, and that each application would define more specifically which
Domain Name Record type it would use. The existent application
specifications (RadioVIS, RadioEPG) would continue to use SRV, but new
application specifications could use other types.
This has an implication for client implementations (devices and
manufacturers), who would then have to request and parse DNS responses
for a wider range of record types than currently.
Please comment on whether you would support a change to allow
individual applications to define the Domain Name Record type used to
advertise them, and a removal of explicit mentions of SRV records in
the core specification in favour of a more generic Domain Name Record.
Nick Piggott
Chairperson
RadioDNS Project
http://radiodns.org // @RadioDNS
Mo McRoberts
On 15 Aug 2011, at 19:00, Nick Piggott (RadioDNS) wrote:
> This has an implication for client implementations (devices and
> manufacturers), who would then have to request and parse DNS responses
> for a wider range of record types than currently.
It would strike me that the impact of requesting & parsing an additional RRtype for a given application would pale into insignificance as compared to the impact of actually implementing that application?
I suppose the key question is whether there are any client implementations rolling their own resolver libraries instead of using one of the permissively-licensed ones that're out there?
Even so, it would seem to me to be an application-level issue to be worked out — if application X specifies, say, NAPTR and manufacturers have an issue with that, then it's a problem for those responsible for application X rather than RadioDNS per se.
M.
Dave Cridland
> Patrik commented on the use of SRV records to advertise
> applications,
> and asked why other Domain Name Record types such as NAPTR and URI
> were not supported.
Right, this is something I suggested way back when.
NAPTR records - and the bigger picture of how to use them within DDDS
- allow you to take a domain name (probably constructed from a
URN), and transform it into an output URI, SRV lookup, or hostname.
In their full form, a NAPTR lookup returns a kind of processing
script to provide the output, including regular expression rewrites
of the query, and other exciting things.
NAPTR records are extremely complex - they'd require devices to
support regular expressions, for instance - but there's two profiles
which are significantly simpler:
1) S-NAPTR (Straightforward NAPTR, pronounced "Snap-Tor") is the
simplest, and allows the results to be only an SRV lookup or an A
lookup. It's defined in RFC 3958, alongside a DDDS application which
is pretty clsoe to what RadioDNS would want. It only allows SRV or
hostname outputs - basically it just mandates that the regexp is not
used.
2) U-NAPTR (URI-Enabled NAPTR, pronounced "Una-Pointer") takes
S-NAPTR and adds back in URI support, but only as complete
replacements - so the regexp is allowed, but is always of exactly the
same form, and doesn't need a real regexp parser to handle it. It's
defined in RFC 4848.
I specifically think the benefits of U-NAPTR would outweight the
additional complexity of handling NAPTR records, in particular they'd
give you much neater URI support, and potentially multiprotocol
support (so you could lookup the RadioDNS domain and find RadioVIS
services over both STOMP and XMPP if you wanted).
Dave.
--
Dave Cridland - mailto:da...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Andy Buckingham (RadioDNS)
being an application issue, rather than the core spec.
If I recall correctly in early RadioDNS drafts the application
discovery bit was specific to the app specs and not in the core. We
eventually decided to briefly discuss the SRV resolution methodology
in the core spec to "complete" the overview of the whole process from
broadcast params to app and to attempt to standardise a way for all
app discovery to work, at the benefit of ease of implementation for
multiple applications.
I still believe there is nothing stopping the Application X spec from
defining an alternative method of discovery if the specifiers so
choose that path. We could then move to a position where to support
core RadioDNS functionality you MUST implement SRV discovery, you MAY
support other methods defined by the specification of the apps you
wish to support". Wording along these lines may clarify this situation?
With regard to NAPTR, as the applications currently devised are often
more complicated than just linking a broadcast service to a single
resource at a URI, it still seems worthwhile to have the fundamental
building blocks of a host and port to be passed in to an additional
spec which more specifically explains the way to utilise those values.
For example,
RadioVIS would have to use records to signify the STOMP and HTTP
protocols, the host, port, the topic - all in a URL. That would mean a
fairly standard implementation having at least 4 URI records minimum
(Stomp Image topic, Stomp Text topic, HTTP Image topic, HTTP Text
topic). If you then extend that to define multiple servers that number
of records grows and grows. Whilst not necessarily being a huge
concern, I do wonder if this poses problems for very slim devices
parsing large DNS response payloads.
Based on feedback from those implementing RadioDNS applications, some
DNS providers do not currently support SRV records. I suspect support
for NAPTR may be even sparser, which would make this another adoption
consideration.
Another point of interest was the suggestion of holding those
application records actually on radiodns.org, so a single lookup could
be performed (e.g. _radiovis._tcp.09580.c586.ce1.radiodns.org to
discover VIS on Capital FM London). This was discussed early on in the
project and was dismissed due to the additional requirements for
RadioDNS as the linking entity. We have always strived to keep
radiodns.org's required function as basic as possible. By offloading
application advertisement to the broadcaster on the second domain
lookup, they remain more tightly in control and it eases the burden on
the RadioDNS organisation.
Fundamentally, it seems this approach moves more complexity up the
"stack" to the DNS level, whereas in the current implementation DNS is
relatively simple adding more complexity as we get to the application
level. Considering that some service providers technical environment
make DNS changes and administration more tricky than modifications at
the application level, this is another important consideration.
Andy.