[dnssd] Comments on draft-ietf-dnssd-hybrid-00

[Tom Pusateri <[e-mail]>]

Thanks for the new draft. The updates did a good job of clarifying some areas.

There were two issues I brought up on the list regarding the previous Hybrid Proxy draft that weren't addressed in this update.

1. The Hybrid Proxy needs to respond with an SOA record for LLQ Discovery. A mention of this plus including recommendations for SOA response values would be very helpful.

Here are the values I'm using:

Serial: number of seconds since the epoch (Since this value can change more than 99 times per day, current conventions for the serial number don't work.)
Expire: 24 hours
Refresh: this is probably meaningless in the context of the proxy but I'll use 2 hours
Retry: this is also probably meaningless but I'll use 30 minutes
Min TTL: the default negative TTL [RFC 2308] could be used in the context of the proxy but this isn't clear because the NSEC records are impossible to proxy for since we don't know all of the records. I'll use 30 minutes.

2. In section 3.4, it describes the translation of certain record types that may be required by the hybrid proxy.

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.4 as another example of necessary data translation.

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.

But since there is no way for the proxy to know all of the records in the subdomain since they are discovered dynamically, the NSEC record should probably just be filtered altogether and never translated.

Filtering of NSEC records is not mentioned in this draft.


Thanks,
Tom