[dnssd] Comments on draft-ietf-dnssd-srp

["Ray Hunter (v6ops)" <[e-mail]>]

Hi,

I've read your draft https://tools.ietf.org/html/draft-ietf-dnssd-srp-02

In general, this draft is very useful and well-written. I can see how it 
would integrate with Homenet, and support it.

Comments:

Section 2

/ If the DNS
    Search List option contains more than one domain name, it MUST NOT be
    used.  If neither option is available, the Service Registration
    protocol is not available on the local network./

Q. This covers if one source contains multiple names in the DNSSL, but 
what if the different sources of <domain> contain conflicting domains 
e.g. DHCPv4 option is inconsistent with RA?

Q. Any special treatment needed? IPv6 preferred?

/Anycasts are sent using UDP unless TCP is required due to the size of 
the update./

Q. Would a compliant server implementation have to support both?

Q. Why only UDP and TCP transport, and not DNS over TLS ((7858) or DNS 
over HTTPS (8484) for example?
Is this draft not actually just transport agnostic?

/It is the responsibility of a Constrained-Node Network supporting SRP to
    provide appropriate anycast routing to deliver the DNS updates to the
    appropriate server./

Q. Do you want to add any additional text to constrain/filter the 
anycast scope?
Would we want anycast traffic leaving the home? [privacy/security]
Recommend setting a max TTL?
ULA anycast rather than GUA?
Further references to RFC7723 and detailed handling of the anycast address?
Does the assignment have to be made in a standards track document or 
informational?

Section 2.1

/The Host Description records for a service are a KEY RR, used to
       claim exclusive ownership of the service registration, and one or
       more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of
       the host where the service resides./

Q. Does publishing a A or AAAA Host Description RR automatically mean 
that the SRP server will create an associated PTR RR for the reverse 
address-> name, does the client have to create this explicitly itself, 
or don't you care?

Section 2.2

/ SRP server handle rewriting that to a different domain if necessary./

How an SRP server re-writes is out of scope?
TTL should also be copied in the rewriting? [include a forward pointer 
to 2.5]
How to handle name clashes if there are multiple SRP servers on 
different technology segments re-writing to one common domain?
SRP server acts as a proxy when re-writing, and if necessary, defends 
the existing name that has been learned from the other segments? (2.3.1)

Section 2.3.1
What if the SIG0 matches, but the RR's don't e.g. if a node moves 
segments and changes IPv6 address? Over-write of existing records is 
explicitly allowed or denied?
Or does the client need to explicitly delete it's old RR's itself first? 
[include a forward pointer to section 2.4.2]

Any differences in how RCODE is specified compared to RFC2136?

Dumb question: Are you overloading port 53?
Is there any potential for confusion or conflict between an SRP server 
(DNS Update Lite) and a DNS server that supports full DNS update?
SRP server only ever listens on the anycast address?


-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>