Kerberos transport DNS record design
mrogers at redhat.com
Thu May 26 11:28:11 EDT 2016
On 05/26, Nathaniel McCallum wrote:
> On Wed, 2016-05-25 at 17:48 -0400, Greg Hudson wrote:
> > * Do we want to make our payload isomorphic to the URI payload, in
> > anticipation of migrating to the URI record type in the future? I
> > would argue that such a migration is vanishingly unlikely. If we
> > go
> > this way, the payload contains a priority, a weight, and a URI, so
> > we
> > have to encode everything but the priority inside a URI, opening a
> > bunch of other inter-related questions:
> It is my preference to support a future migration to URI, even if we
> grant that such a trasition is vanishingly unlikely. Doing so adds no
> additional burden to our implementation since we already have to
> process a URI for KKDCP. Put short, we will have to write a parser for
> whatever format we use. Thus, I think our default should be to use a
> URI format unless there is a compelling reason not to.
> > - Should we register a new URI scheme to represent TCP and UDP
> > transports, or use the unregistered tcp: and udp: schemes as some
> > other applications have done?
> > - Should we use a new URI scheme (probably the same one as above)
> > for
> > MS-KKDCP, or should we just use the https: URI of the proxy?
> I do not have any strong preference for the format. Something like this
> might work:
No particular preference here, so this format is fine to me.
> > - Should we use fragment identifiers (#suffix) to indicate master-
> > ness
> > and/or the transport type, or should we use a prefix?
> It is my preference to avoid fragments. Colon separation logic can't be
> reused for fragments, so we just add an additional parsing burden. I'd
> like to avoid this complexity.
> > * At the bikeshed level, what should we use as a separator between
> > fields? Is it more convenient for DNS administrators if we avoid
> > using whitespace as a separator?
> As I said above, we already have to parse a URI for KKDCP, let's resuse
> this parsing logic. I'm against whitespace separators for this reason.
+1 on both points.
> krbdev mailing list krbdev at mit.edu
Red Hat, Inc
More information about the krbdev