Kerberos transport DNS record design

[Brandon Allbery]

Discovery sounds right to me; using your own example, discover the KDCs available in the local realm --- or some other realm. It's a matter of whether you think of a KDC as defining the realm, or as a service of the realm; and to my mind, this seems more like the former with traditional KDC organization but the latter with LDAP backing. And I'd view this whole thing administratively as transitioning from the former to the latter, since if the KDCs define the realm then they should be known up front, otherwise you don't "know" the realm even if you have a name for it.

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Greg Hudson
Sent: Wednesday, June 1, 2016 11:33 AM
To: Matt Rogers <mrogers at redhat.com>
Cc: krbdev at mit.edu
Subject: Re: Kerberos transport DNS record design

On 06/01/2016 10:49 AM, Matt Rogers wrote:
> The wiki page should be up to speed now. I added some additional notes 
> about priority and fallback behavior that were discussed in IRC. A 
> quick review would be appreciated.
> 
> https://k5wiki.kerberos.org/wiki/Projects/KDC_Discovery

* I'm not sure the term "discovery" is correct, since we know a realm name and are just trying to figure out how to contact it.  (Compare to "discover the printers available on my local network.")

* The TXT payload is not formatted using a URI.  We believe we could transition to URI by creating a new URI scheme and stuffing everything after the weight into the residual part of the URI.  But there is no URI scheme in the payload, and we don't plan to register this URI scheme until we need it.

* The 'M' (master) flag is only relevant to KDC lookups, but other future flags might not be.  So saying that the flags field is ignored for kadmin and kpasswd lookups is problematic.

* I wouldn't bother describing the "tls" transport.  It was just an example of a possible future transport.

* There is no currently defined or implemented http transport for MS-KKDCP (there is only https).

* I would just specify that priority and weight are as defined in RFC 2782, and that weight may or may not be implemented while priority must be.

Also, we should explicitly decide whether flag letters are case-sensitive.  In a side conversation on IRC, Simo argued that DNS data is traditionally case-insensitive.  I don't have an opinion.
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev