Subject: [dnssd] draft-cheshire-dnssd-hybrid-01 & NSEC records

From: Tom Pusateri <[email-masked]>
Date: Tue, 25 Mar 2014 17:55:39 -0400

In section 3.1, it describes the translation of certain record types that may be required by the hybrid proxy.
Here's an example of one that isn't listed in section 3.1 but maybe should be.

A unicast query is received by the proxy for _domain._udp.Building 1.example.com. and a query is sent for _domain._udp.local. to the appropriate interface and this response is received:

q: 1, tc: 0, qd: 0, an: 1, ns: 0, ar: 3, rcode: No Error
hypd:   rname: _domain._udp.local., rrtype: SRV, rrclass: 1, rrset: 0, ttl: 120, data: foo.local.
hypd:   rname: foo.local., rrtype: AAAA, rrclass: 1, rrset: 1, ttl: 120, data: fe80::2a37:37ff:fe40:4462
hypd:   rname: foo.local., rrtype: A, rrclass: 1, rrset: 1, ttl: 120, data: 198.51.100.1
hypd:   rname: foo.local., rrtype: NSEC, rrclass: 1, rrset: 1, ttl: 120, data: foo.local. A AAAA

This response contains a link-local IPv6 address which should be filtered before the unicast response is generated.

Specific mention of rewriting the NSEC bitmap of records present to remove the AAAA bit could be added to section 3.1 as another example of necessary data translation.

However, RFC 6762, Section 6.1 states that the Next Domain Name in the RDATA section is the record's name and name compression is allowed. RFC 3845 which defines NSEC says name compression is not allowed and the Next Domain Name is the next name in lexicographical order.

So, should proxy follow the unicast guidelines or the multicast guidelines? In the case above, should I just filter the AAAA record and record present bit in the NSEC record? Or should I drop the NSEC record altogether? Or should I change the Next Domain Name and stop using compression?

Thanks,
Tom

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Mar 2014 15:25:09 -0700

> So, should proxy follow the unicast guidelines or the multicast guidelines? In the case above, should I just filter the AAAA record and record present bit in the NSEC record? Or should I drop the N…

Dear Tom,

Any translation from mDNS must conform to DNS and not mDNS requirements.  NSEC records in mDNS are NOT valid NSEC records for DNS.

One motivation for extending mDNS is overcome by extending AirPlay over Bluetooth by the latest generation AppleTV.  It should also be noted no HDCP scheme permits even one network hop.  I still insist a proper solution would use RBridge or VLAN.  Even so, larger configurations should still filter out undesired services from being extended.

The recommendation is to filter out link-local addresses.  Blithely populating DNS with mDNS names with their addresses pinned to a routable address by way of a NAT represents a poor practice.

At the presentation, someone suggested mDNS must work over networks unable to handle multicast.  In that case, something like Active-Directory or DNS must be used natively. In such cases mDNS has no role.

Regards,
Douglas Otis