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/rfc1035https://tools.ietf.org/html/rfc6763www.dns-sd.orgThanks