SRV records for DNS-SD Service Discovery

[loafbread]

How can I add a "named service" to an SRV record?  It seems your GUI requires the Domain to start with an underscore.  I need to precede the "Domain" with a name because I want multiple SRV records for the same service protocol.  For instance, I want multiple _http._tcp SRV records.  I need to preceed the _http._tcp with a name such as WebService1._http._tcp to distinguish between a second _http._tcp SRV record. 

See this for an example: http://www.dns-sd.org/ServerStaticSetup.html

[snarked]

Nonstandard uses, including Micro$oft corruptions, should not be supported without good reason.

SRV record labels are strictly defined as:

_<service>._<protocol>.<host>.<domain>.

What you seem to be referencing is:  draft-cheshire-dnsext-dns-sd-11.txt.  That isn't even a proposal ready for comment yet.  Given that, I would clearly object to it.  "Instance" should logically be a label between protocol and host to be consistent with previously published and accepted RFCs and standards.  Furthermore, overloading the PTR-RR to require additional section processing for certain labels when RFC 1035 (the current DNS standard) indicates no such processing simply won't work.  Thus, this proposal is broken.

RFC 1035, page 18:

PTR records cause no additional section processing.

The proposal should probably use CNAME-RRs instead as those may have additional processing when the original query was another RR-type and the queried server performs internal recursion.

[loafbread]

Fair enough.

[agnuswiz]

What you seem to be referencing is:  draft-cheshire-dnsext-dns-sd-11.txt.  That isn't even a proposal ready for comment yet.  Given that, I would clearly object to it.  "Instance" should logically be a label between protocol and host to be consistent with previously published and accepted RFCs and standards.  Furthermore, overloading the PTR-RR to require additional section processing for certain labels when RFC 1035 (the current DNS standard) indicates no such processing simply won't work.  Thus, this proposal is broken.

RFC 1035, page 18:

PTR records cause no additional section processing.

The proposal should probably use CNAME-RRs instead as those may have additional processing when the original query was another RR-type and the queried server performs internal recursion.

Major bump here.

"draft-cheshire-dnsext-dns-sd-11.txt" is now a Proposed Standard (since Feb 2013) as RFC 6763. And I think the intent in the text is that the Service Instance PTR records *shouldn't* require any additional section processing since they are textual descriptions primarily intended for the end user's eyes. Only when the user selects a specific instance to "work with" (in some context) is the SRV query performed. That's how I interpret the text, anyway.

That's probably also why the RFC recommends that applications using DNS-SD should always perform the name-to-address resolution as late as possible to avoid caching information that may be subject to frequent change.

Long story short: Is this (i.e. Service Instance names in SRV records) something HE would consider allowing in the future? I for one would be delighted, and it seems there's at least one more :-)

Regards,
/agnuswiz

[HoudWarZ]

I have also bumped onto that limitation after delegating a sub-domain from GoDaddy to DNS.HE.NET specifically for implementing DNS-SD feature as HE.NET supports PTR records ... bummer.

Even though I fancy the DNS-SD standard for easy discovery of all sorts of devices and applications, I agree with snarked comments that this is some kind of abuse of SRV records made by the DNS-SD standard... But so far BIND and MS DNS servers support it anyway from long ago.

I have made several tests and we don't have any better option as the DNS-SD clients (Apple's Bonjour) will ignore a PTR if it is outside of the SRV service domain:

This <better> pattern (HE.NET friendly) is ignored from the DNS-SD clients:
(Clients are not even trying to query for the SRV and TXT records)

_printer._tcp             PTR   _printer._tcp.MYTARGET.domain.tld.
_printer._tcp.MYTARGET    SRV   [...]
_printer._tcp.MYTARGET    TXT   [...]

This second <better> pattern (HE.NET friendly) is also ignored or not understood from the DNS-SD clients:
(The clients are not clever enough to try querying for the SRV and TXT records at _printer._tcp.MYTARGET.domain.tld)

_printer._tcp             PTR   MYTARGET.domain.tld.
_printer._tcp.MYTARGET    SRV   [...]
_printer._tcp.MYTARGET    TXT   [...]



Only version interesting to the clients are those in this specific format (not HE.NET friendly):

_printer._tcp             PTR   MYTARGET._printer._tcp.domain.tld.
MYTARGET._printer._tcp    SRV   [...]
MYTARGET._printer._tcp    TXT   [...]



#############


For these reasons, my request to HE.NET is if it is possible to relax their SRV record domain naming pattern to allow usage of RFC 6763 proposed standard ?
If the answer is positive for implementation, let's not forget that DNS-SD names can also have sub services such as:

_universal._sub._printer._tcp       PTR   MYTARGET._printer._tcp.domain.tld.
_printer._sub._http._tcp            PTR   MYTARGET._printer._tcp.domain.tld.
MYTARGET._printer._tcp              SRV   [...]
MYTARGET._printer._tcp              TXT   [...]


References:
https://tools.ietf.org/html/rfc1035
https://tools.ietf.org/html/rfc6763
www.dns-sd.org

Thanks

[HoudWarZ]

Hello,

Good news !
DNS.HE.NET now supports RFC 6763 !

I have forwarded a copy of my post directly to DNS Support email address and I had the best of surprising reply the next day from their support that they had just relaxed the SRV Record Domain Naming Rules to allow the usage of RFC 6763 address styles ! I tested it and it is working as requested.

Thanks again HE.NET for the greatest of support :)

[snarked]

Just remember that because a feature is published in an RFC doesn't mean that it's a good (or bad) idea.  RFCs are proposals, not standards....  Just because you find a feature useful, good for you, but that does not mean that the Internet community at large will accept it.

[agnuswiz]

Just remember that because a feature is published in an RFC doesn't mean that it's a good (or bad) idea.  RFCs are proposals, not standards....  Just because you find a feature useful, good for you, but that does not mean that the Internet community at large will accept it.

I absolutely agree. That's what makes for so many and wonderfully varied interpretations of the de facto "standard" RFCs :-)

Many thanks, HE!

PS: Just wanted to establish that I'm NOT trying to be sarcastic here.
PPS: The above PS is not sarcastic either. Oh God, this isn't going well...