[dnssd] Some comments on draft-sctl-service-registration-00

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

Hi everyone

I've been meaning to post some comments on
draft-sctl-service-registration-00 for a while; finally got around to
writing this down. These are partly based on differences between what
the draft specifies and my implementation[1].

Since the draft is in somewhat of an early stage, I did not think it
made sense to do detailed section-by-section commenting. So instead,
here follows some general comments for discussion, in no particular
order:


- It is not clear how to find the server to register with: Section 2
  refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to
  RFC6763 Section 11 for information on how to discover the zones to
  attempt registration in. So from my best reading of this, the client
  should discover the relevant zones, then just send its signed updates
  to any authoritative server for those zones. However, this prevents
  implementing the registration logic as a proxy (as I'm currently
  doing). So I feel like there should be a SRV lookup in there
  somewhere? I seem to recall Stuart telling me that this is indeed
  specified somewhere, but my google fu is failing me right now, and in
  any case it's not clear from the draft how this process is supposed to
  work.
  

- Different expiry times for different records: Section 5 mentions that
  the server should keep the SIG(0) public key for much longer than the
  other records, but does not specify how that is to be accomplished.
  If the server just picks a cache time for the key, that effectively
  prevents the client from specifying how long it has this key
  available; think a client with no permanent storage which generates a
  key at startup and keeps it in memory, but wants to make sure it is
  not cached for longer than the other records so it can reclaim it if
  it needs to reboot.

  I currently implement a per-record lease time by overloading the TTL
  of the DNS Update packet coming from the client: The TTL in the update
  packet has the same meaning as the lease time in the current version
  of the draft (except it's per-record), and the server will install the
  actual records into DNS with a different TTL. I'm not sure that is a
  better way to do it, though.
  

- Address-based ACLs: Obviously, in most cases a client should only be
  able to perform registration if it is actually on the right network.
  Firewalling off the ports from outside the relevant networks is a way
  to ensure this, but it is somewhat of a crude tool. For one, it
  prevents a single registration server / proxy from serving multiple
  networks. For another, it prevents a use case where a client is only
  allowed *initial* registration (when the key is first cached) from
  inside the network, but is allowed to subsequently update the same
  record from anywhere. This is useful to, for instance, have my laptop
  maintain my-laptop.myhome.example.org even when visiting another
  network.

  So another way to ensure this source verification is needed, I think.
  The way I implemented it is to have the registration server only speak
  TCP; that way, source address spoofing is not possible (as that would
  make the handshake fail), and the server can simply implement a
  straight-forward ACL policy.
  

- It is not quite clear to me whether the sleep proxy described in
  section 4 is an optional feature or if its meant to be mandatory.
  Stuart explained its usefulness for devices that power off when not in
  use, requiring this function will mean that registration servers will
  need to be on the local link, which is somewhat limiting. Also, the
  implementation complexity goes way up (I certainly don't plan to
  implement this feature :)). So I think having a way for the server to
  signal "no, I can't perform sleep proxying" to the client would be
  good to allow things to fail in a graceful way.


-Toke


[1] https://github.com/tohojo/nsregd