Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

[Rick van Rein <[e-mail]>]

Hi,

I agree mostly with Jeffrey, but have some additional remarks / thoughts.

> _kerberos.REALM
>
> is not a valid DNS URI record name. To translate the URI
>
Yes, the RFC wants it to be of the form _server._transport, however

> https://host[:port][path]
>
> to an URI record requires
>
> _kerberos._https.host

where is _https defined as a transport?  RFC 7553 gives examples with
_http._tcp -- I've always wondered to deal with _https and especially
how to add semantics on top of it, so I certainly like the scheme, but
is this format defined anywhere?  For SRV, I though transports were
limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS?

Nathaniel, I think what you are actually trying to do is to describe
HTTPS as a tunneling technique, right?  Since this type of tunnel is
designed to participate in the rope-pulling contest between application
desires and (perhaps misguided) firewall configurations, it might be
expected that new tunnels would be topped on as time passes.  Clients
would need to keep up, but keep the older solutions working as well.  So
instead, I would rather have some sort of a redirection to a somewhat
general tunnel descriptor as a general discovery outcome when looking
for a "direct" service description.  This would service many
applications in the same manner.

> registering additional service types such as "kpasswd" can be done but
> the fact is implementations such as Heimdal already perform SRV
> lookups for
>
> _kpasswd,_tcp.REALM and _kpasswd._udp.REALM
>
> Can you make a case for something that DNS URI records provides that DNS
> SRV records do not?
>
It should outweigh having to do both forever and ever, indeed.  And
needing to add even more when other tunneling techniques arrive.

I hope this helps!


Cheers,
 -Rick