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

[Toke Høiland-Jørgensen <[e-mail]>]

Ted Lemon <[e-mail]> writes:

>> 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.

Right. I *think* that will work; but will probably have to try it out to
be sure :)

>> - 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. :)

I'm fine with not having that argument; just want to make sure the
standard doesn't disallow it (auto-adding). See below.

> - 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.

What I implemented is that the client will add AAAA records for all
addresses assigned to the interface; and the registration server will
filter out the ones it doesn't like (mostly making sure site-local
addresses don't end up in global DNS). I think this sort of thing should
be allowed at the server side (could also be a policy like "we don't
want printers on this network").

The question is if the client should be notified; my server will tell
the client which records were actually created, and the client won't
bother maintaining the ones that weren't. However, this is mostly an
optimisation; not sure if it's worth specifying in the spec...

>> - 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.

Right, that's what I thought.

> 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! :)

Hmm, don't think it read like it's required, necessarily; I was just
confused by it. I consider(ed) the reverse domains a static thing not
likely to change, in which case it seems odd to do the mapping from
.local. Is this what happens in mDNS?

-Toke