Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

[Ted Lemon <[e-mail]>]

On Thu, Jul 12, 2018 at 6:40 AM, Toke Høiland-Jørgensen <[e-mail]>
wrote:

> Thanks for the update! I think this version addresses my concerns from
> the previous round. :)
>

Great!


> A few other comments based on a quick read-through:
>
> - Since registrations are always done with .local, it is up to the
>   registration server to decide which domain(s) the registration ends up
>   in, right? How is it supposed to do that if servicing multiple zones?
>   Just based on source IP?
>

I think that that's up to the implementation.  It could do it based on IP
address, or as I suggested in the document it could have a whitelist that's
maintained by an administrator, based on the key or the name or the service
type.   As long as it does the same thing every time, the details are (I
think) immaterial.   However, this is worth thinking about—if you can come
up with something that doesn't work, we should document it.


> - The document says that clients must generate their own reverse PTR
>   records. Should the server be able to do that on the clients behalf?
>   It may be a matter of policy which ranges have reverse domain
>   delegations...
>

Interesting.   I did it this way because I don't want to get into the "PTR
is bad, get rid of it, no it's good, I want it" argument. :)

It could certainly be a site policy to auto-add a PTR record.   Since the
content of the PTR record is fixed, this would just have the effect of
making PTR records non-optional, not of changing what got stored in the
update.   I would be in favor of adding this as an optional behavior.

However, I think that this should be optional behavior, and therefore I
think it's worth allowing the client to update the PTR record.   The
benefit of this is that it gives the software/hardware vendor some say in
what debugging information is available, regardless of the opinions of the
network operator or DNS server implementor.

- Related to the above, is it permitted for the registration server to
>   modify the records submitted by clients before putting them into
>   DNS? For example, to add PTR records, or to remove a subset of the
>   records etc? The alternative to modifying would be to reject the whole
>   registration if a subset is not admissible. If the server *is* allowed
>   to modify things, should it communicate back to the client what it
>   really did?
>

Can you think of a scenario where it makes sense to do this?   The reason
that this might not be permissible is simply that I can't think of a record
other than the PTR record that could be omitted without making things fail.


> - You mention in the text that a network may use a different domain than
>   ip6.arpa for reverse PTRs. How does that work? Won't clients always
>   do reverse lookups to ip6.arpa?


Unless they are modified.   The point of that is not to suggest that
implementing this is REQUIRED, but it could be useful for someone, and
hence is not FORBIDDEN.  If you think the text reads as making this a
required feature, we should fix that!   :)