Kerberos transport DNS record design

[Greg Hudson]

Currently we can map from a Kerberos realm name to the TCP and/or UDP
addresses of a KDC, kpasswd, or kadmind server. Several of us have been
discussing how to best extend that mechanism to include MS-KKDCP, and at
the same time minimize the number of DNS lookups required to contact a
realm without configuration.

We had been planning to use the URI record type, but after a recent
round of discussion, we don't think it's likely that popular DNS hosting
providers will allow customers to create URI records (since it seems
like no one else is using them). Some middle-boxes would also block DNS
queries for URI records. That problem would be even worse if we create
a new record type. So, we are planning to use the TXT record type. It
seems unlikely that we can standardize on a TXT record through the IETF
(except perhaps as an informational RFC), but it seems like the only
deployable option for individuals and small organizations.

If we use the TXT record type, we have to define the payload format,
which is the primary subject of this thread. The payload must
communicate:

* Priority, because DNS records are unordered
* Transport type--currently one of TCP, UDP, and MS-KKDCP
* For the TCP and UDP types, the hostname and optional port
* For the MS-KKDCP type, the proxy URL

The format must be extensible to future transport types, including
ones that use TCP, UDP, or HTTP in different ways. Examples could
include Heimdal's HTTP proxy protocol or RFC 6251 (Kerberos over TLS).

That leaves a lot of questions:

* Do we want to include weights as well as priorities? I think weights
are unnecessary complexity, even just as an optional field in the
format, but I seem to be in the minority.

* Do we want to include master KDCs in the same query as normal KDCs, or
should they be in a separate record? (Master KDCs are used as a
fallback by the MIT client code when we receive a KDC error which
could have resulted from out-of-date data due to propagation delays.)

- If we do communicate master KDCs in the same record, should it be
possible to exclude a master KDC from the normal server list (so
that it is only contacted if a normal KDC returns an error), or is
it sufficient to be able to assign master KDCs a low priority?

* 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:

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

- If we do create new URI schemes, should we use use separate schemes
for krb5/kpasswd/kadmin, or use the same scheme since we already
know the application protocol going in?

- Should we use fragment identifiers (#suffix) to indicate master-ness
and/or the transport type, or should we use a prefix?

If we don't restrict ourselves to an isomorphic-to-URI payload format,
we still have to decide whether and how to represent master KDC
entries, but the other concerns largely go away.

* 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?
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nathaniel McCallum]

Post by Greg Hudson
Currently we can map from a Kerberos realm name to the TCP and/or UDP
addresses of a KDC, kpasswd, or kadmind server.  Several of us have
been
discussing how to best extend that mechanism to include MS-KKDCP, and at
the same time minimize the number of DNS lookups required to contact a
realm without configuration.
We had been planning to use the URI record type, but after a recent
round of discussion, we don't think it's likely that popular DNS hosting
providers will allow customers to create URI records (since it seems
like no one else is using them).  Some middle-boxes would also block
DNS
queries for URI records.  That problem would be even worse if we
create
a new record type.  So, we are planning to use the TXT record
type.  It
seems unlikely that we can standardize on a TXT record through the IETF
(except perhaps as an informational RFC), but it seems like the only
deployable option for individuals and small organizations.
If we use the TXT record type, we have to define the payload format,
which is the primary subject of this thread.  The payload must
* Priority, because DNS records are unordered
* Transport type--currently one of TCP, UDP, and MS-KKDCP
* For the TCP and UDP types, the hostname and optional port
* For the MS-KKDCP type, the proxy URL
The format must be extensible to future transport types, including
ones that use TCP, UDP, or HTTP in different ways.  Examples could
include Heimdal's HTTP proxy protocol or RFC 6251 (Kerberos over TLS).
* Do we want to include weights as well as priorities?  I think
weights
  are unnecessary complexity, even just as an optional field in the
  format, but I seem to be in the minority.

It is my strong preference to include weight so that implementations
which already have weight processing logic can utilize this
information. MIT does not need to support it unless clear justification
presents itself.

Post by Greg Hudson
* Do we want to include master KDCs in the same query as normal KDCs, or
  should they be in a separate record?  (Master KDCs are used as a
  fallback by the MIT client code when we receive a KDC error which
  could have resulted from out-of-date data due to propagation
delays.)
  - If we do communicate master KDCs in the same record, should it be
    possible to exclude a master KDC from the normal server list (so
    that it is only contacted if a normal KDC returns an error), or
is
    it sufficient to be able to assign master KDCs a low priority?

If the only reason to specify a master KDC is as a last-ditch fallback,
then priority should be sufficient.

Post by Greg Hudson
* 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

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.

Post by Greg Hudson
  - 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:

priority:weight:krbkdc:udp:host[:port]
priority:weight:krbkdc:tcp:host[:port]
priority:weight:krbkdc:tls:host[:port]
priority:weight:krbkdc:kkdcp:http://host[:port][/path]
priority:weight:krbkdc:kkdcp:https://host[:port][/path]

Post by Greg Hudson
  - If we do create new URI schemes, should we use use separate
schemes
    for krb5/kpasswd/kadmin, or use the same scheme since we already
    know the application protocol going in?

Is there any value in having a single query return both kpasswd and
kadmin? If so, then I think separate schemes are desirable.

Post by Greg Hudson
  - 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.

Post by Greg Hudson
* 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.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman

[Greg Hudson]

Post by Nathaniel McCallum

Post by Greg Hudson
* Do we want to include master KDCs in the same query as normal KDCs, or
should they be in a separate record? (Master KDCs are used as a
fallback by the MIT client code when we receive a KDC error which
could have resulted from out-of-date data due to propagation delays.)
- If we do communicate master KDCs in the same record, should it be
possible to exclude a master KDC from the normal server list (so
that it is only contacted if a normal KDC returns an error), or is
it sufficient to be able to assign master KDCs a low priority?

If the only reason to specify a master KDC is as a last-ditch fallback,
then priority should be sufficient.

Priority only affects the order in which KDCs are contacted when
higher-priority KDCs fail to answer at all. Master KDCs are used as a
fallback if a non-master KDC returns an error like "preauth failed"
which could result from stale KDC data.

So, priority might be a sufficient alternative to "master only," but it
cannot handle the problem entirely. If we do not include an indication
of master KDCs in the TXT record payload, we will have to make a second
query of another record to find them. (In theory this query is only
necessary on failure, but currently the code does it whenever it gets a
KDC response.)
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nathaniel McCallum]

Post by Greg Hudson

Post by Nathaniel McCallum

Post by Greg Hudson
* Do we want to include master KDCs in the same query as normal
KDCs,
or
  should they be in a separate record?  (Master KDCs are used as a
  fallback by the MIT client code when we receive a KDC error which
  could have resulted from out-of-date data due to propagation
delays.)
  - If we do communicate master KDCs in the same record, should it be
    possible to exclude a master KDC from the normal server list (so
    that it is only contacted if a normal KDC returns an error), or
is
    it sufficient to be able to assign master KDCs a low priority?

If the only reason to specify a master KDC is as a last-ditch fallback,
then priority should be sufficient.

Priority only affects the order in which KDCs are contacted when
higher-priority KDCs fail to answer at all.  Master KDCs are used as
a
fallback if a non-master KDC returns an error like "preauth failed"
which could result from stale KDC data.
So, priority might be a sufficient alternative to "master only," but it
cannot handle the problem entirely.  If we do not include an
indication
of master KDCs in the TXT record payload, we will have to make a second
query of another record to find them.  (In theory this query is only
necessary on failure, but currently the code does it whenever it gets a
KDC response.)

How likely is this failure from non-master KDCs due to synchronization
issues? Is this a real historical problem? Does this problem persist
today?

Does anyone else implement this logic?
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit

[Greg Hudson]

Post by Nathaniel McCallum
How likely is this failure from non-master KDCs due to synchronization
issues? Is this a real historical problem? Does this problem persist
today?

Any site with a non-trivial replication delay can be affected by this
problem whenever users change their passwords. It is a real historical
problem, and it persists as a concern for the MIT KDC deployment. I
don't have a lot of visibility into other deployments, but we have
received a request within the last few years to expand the master
fallback to TGS requests.

Post by Nathaniel McCallum
Does anyone else implement this logic?

I don't see any evidence that Heimdal implements it, so we may be the
only one. It's a legitimate question how Heimdal gets away with not
implementing this fallback. If you list your master KDC first in the
KDC list, then the frequency of kinit failures after a password change
goes way down, but I've measured as high as a 1% fallback rate in the
MIT Kerberos deployment when the master KDC is operational.

I don't think we're currently in a position to simplify out this part of
the initial creds design. Complexity, once added, is hard to safely remove.

Post by Nathaniel McCallum
It is my preference to support a future migration to URI, even if we
grant that such a trasition is vanishingly unlikely.

The main cost here is registering one or more URI schemes, unless we
decide to shoehorn our responses into existing schemes. See RFC 7595
for the procedures involved. It also makes the DNS responses slightly
larger since the URI scheme (completely predictable if we register our
own) needs to appear in each record.

Post by Nathaniel McCallum
Is there any value in having a single query return both kpasswd and
kadmin? If so, then I think separate schemes are desirable.

I don't think there is any value in including kpasswd and kadmin entries
in the same record. While we do fall back from kpasswd to port-changed
kadmin when locating kpasswd servers, this is only a provision for
realms with misconfigured DNS.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Brandon Allbery]

As someone with admin experience with both MIT and (older versions of) Heimdal:

- MIT's propagation mechanisms are somewhat limited; either you do bulk propagation at set times, which leads to changes between those times not being seen in a timely fashion on the slave KDCs, or you can use incremental propagation which only works reliably with a relatively low change rate and is prone to stalling and eventually failure as the change rate increases.

- It took Heimdal quite a while to get its incremental propagation (iprop) to be reliable, but in reasonably recent versions iprop does not have the stability issues under moderate to high change rates that MIT's kiprop has. As such, iprop makes master KDC fallback unnecessary in most cases.

- For either one, using LDAP backend with its replication facilities makes fallback unnecessary.

-----Original Message-----
From: krbdev-***@mit.edu [mailto:krbdev-***@mit.edu] On Behalf Of Greg Hudson
Sent: Thursday, May 26, 2016 1:10 PM
To: Nathaniel McCallum <***@redhat.com>; ***@mit.edu
Subject: Re: Kerberos transport DNS record design

Post by Nathaniel McCallum
How likely is this failure from non-master KDCs due to synchronization
issues? Is this a real historical problem? Does this problem persist
today?

Any site with a non-trivial replication delay can be affected by this problem whenever users change their passwords. It is a real historical problem, and it persists as a concern for the MIT KDC deployment. I don't have a lot of visibility into other deployments, but we have received a request within the last few years to expand the master fallback to TGS requests.

Post by Nathaniel McCallum
Does anyone else implement this logic?

I don't see any evidence that Heimdal implements it, so we may be the only one. It's a legitimate question how Heimdal gets away with not implementing this fallback. If you list your master KDC first in the KDC list, then the frequency of kinit failures after a password change goes way down, but I've measured as high as a 1% fallback rate in the MIT Kerberos deployment when the master KDC is operational.

I don't think we're currently in a position to simplify out this part of the initial creds design. Complexity, once added, is hard to safely remove.

Post by Nathaniel McCallum
It is my preference to support a future migration to URI, even if we
grant that such a trasition is vanishingly unlikely.

The main cost here is registering one or more URI schemes, unless we decide to shoehorn our responses into existing schemes. See RFC 7595 for the procedures involved. It also makes the DNS responses slightly larger since the URI scheme (completely predictable if we register our
own) needs to appear in each record.

Post by Nathaniel McCallum
Is there any value in having a single query return both kpasswd and
kadmin? If so, then I think separate schemes are desirable.

I don't think there is any value in including kpasswd and kadmin entries in the same record. While we do fall back from kpasswd to port-changed kadmin when locating kpasswd servers, this is only a provision for realms with misconfigured DNS.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Roland C. Dowdeswell]

Post by Brandon Allbery
- For either one, using LDAP backend with its replication facilities
makes fallback unnecessary.

Does the LDAP backend promise that all of the slaves are up to date
before kadm5_create_principal() returns successfully? If not,
there will still be a race condition. We are currently starting
to see our developers deploy new services using VMs and containers
in an on-demand fashion on a large scale expecting to be able to
hit those services the moment the master KDC reports that the
principal has been created.

I also quite like the master failover because it provides additional
resiliency against things like: a slave's clock going out of skew;
an administrator truncating the Kerberos DB on a slave; a slave
running out of disk space and somehow rubbishing the KDB causing
the KDC to respond inappropriately; or an administrator of DNS
(often people in a different group in the organisation) messing up
the one of the SRV RRs to point at a different realm's KDC. I
suppose that I don't think that it makes sense for the client to
simply give up at the first sign of errors when there is a decent
chance that one of the other KDCs may very well have a better
answer. Remember that in many environments, almost all requests
to the KDCs should succeed, after all: if I'm making a TGS_REQ for
a service then in general I've connected to the service in question
and it has asked me to use GSSAPI/Kerberos authentication (at least
in the case of protocols like HTTP/Negotiate, SSH, SASL where GSSAPI
auth is negotiated.)

[Brandon Allbery]

None of the backends provides a guarantee that all slaves are updated; in fact it is very likely (but not a guarantee) that *no* slave has been updated at that point, regardless of backend. LDAP and Heimdal's iprop would be fastest to update afterward, depending on configuration, and most probably LDAP can be tuned to minimize the time: LDAP does not rely on relatively long delays (measured in minutes instead of seconds) to validate lock-free update semantics, as the KDC-based replications do.

Otherwise, you do make good points about continued utility of the fallback in edge cases.

-----Original Message-----
From: Roland C. Dowdeswell [mailto:***@imrryr.org]
Sent: Thursday, May 26, 2016 10:59 PM
To: Brandon Allbery <***@sinenomine.net>
Cc: Greg Hudson <***@mit.edu>; Nathaniel McCallum <***@redhat.com>; ***@mit.edu
Subject: Re: Kerberos transport DNS record design

Post by Brandon Allbery
- For either one, using LDAP backend with its replication facilities
makes fallback unnecessary.

Does the LDAP backend promise that all of the slaves are up to date before kadm5_create_principal() returns successfully? If not, there will still be a race condition. We are currently starting to see our developers deploy new services using VMs and containers in an on-demand fashion on a large scale expecting to be able to hit those services the moment the master KDC reports that the principal has been created.

I also quite like the master failover because it provides additional resiliency against things like: a slave's clock going out of skew; an administrator truncating the Kerberos DB on a slave; a slave running out of disk space and somehow rubbishing the KDB causing the KDC to respond inappropriately; or an administrator of DNS (often people in a different group in the organisation) messing up the one of the SRV RRs to point at a different realm's KDC. I suppose that I don't think that it makes sense for the client to simply give up at the first sign of errors when there is a decent chance that one of the other KDCs may very well have a better answer. Remember that in many environments, almost all requests to the KDCs should succeed, after all: if I'm making a TGS_REQ for a service then in general I've connected to the service in question and it has asked me to use GSSAPI/Kerberos authentication (at least in the case of protocols like HTTP/Negotiate, SSH, SASL where GSSAPI a!
uth is negotiated.)

--
Roland Dowdeswell http://Imrryr.ORG/~elric/

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

The fallback makes sense in a single-master/multiple-slaves scenario, in
a multi-master scenario it doesn't really do much, as you do not know
*which* master has the new data, but you may be lucky that replication
happened by the time you try again with another server.

Simo.

Post by Brandon Allbery
None of the backends provides a guarantee that all slaves are updated;
in fact it is very likely (but not a guarantee) that *no* slave has
been updated at that point, regardless of backend. LDAP and Heimdal's
iprop would be fastest to update afterward, depending on
configuration, and most probably LDAP can be tuned to minimize the
time: LDAP does not rely on relatively long delays (measured in
minutes instead of seconds) to validate lock-free update semantics, as
the KDC-based replications do.
Otherwise, you do make good points about continued utility of the fallback in edge cases.
-----Original Message-----
Sent: Thursday, May 26, 2016 10:59 PM
Subject: Re: Kerberos transport DNS record design

Post by Brandon Allbery
- For either one, using LDAP backend with its replication facilities
makes fallback unnecessary.

Does the LDAP backend promise that all of the slaves are up to date before kadm5_create_principal() returns successfully? If not, there will still be a race condition. We are currently starting to see our developers deploy new services using VMs and containers in an on-demand fashion on a large scale expecting to be able to hit those services the moment the master KDC reports that the principal has been created.
I also quite like the master failover because it provides additional resiliency against things like: a slave's clock going out of skew; an administrator truncating the Kerberos DB on a slave; a slave running out of disk space and somehow rubbishing the KDB causing the KDC to respond inappropriately; or an administrator of DNS (often people in a different group in the organisation) messing up the one of the SRV RRs to point at a different realm's KDC. I suppose that I don't think that it makes sense for the client to simply give up at the first sign of errors when there is a decent chance that one of the other KDCs may very well have a better answer. Remember that in many environments, almost all requests to the KDCs should succeed, after all: if I'm making a TGS_REQ for a service then in general I've connected to the service in question and it has asked me to use GSSAPI/Kerberos authentication (at least in the case of protocols like HTTP/Negotiate, SSH, SASL where GSSAPI!

a!

Post by Brandon Allbery
uth is negotiated.)
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nathaniel McCallum]

Post by Greg Hudson

Post by Nathaniel McCallum
How likely is this failure from non-master KDCs due to
synchronization
issues? Is this a real historical problem? Does this problem
persist
today?

Any site with a non-trivial replication delay can be affected by this
problem whenever users change their passwords.  It is a real
historical
problem, and it persists as a concern for the MIT KDC deployment.  I
don't have a lot of visibility into other deployments, but we have
received a request within the last few years to expand the master
fallback to TGS requests.

Post by Nathaniel McCallum
Does anyone else implement this logic?

I don't see any evidence that Heimdal implements it, so we may be the
only one.  It's a legitimate question how Heimdal gets away with not
implementing this fallback.  If you list your master KDC first in the
KDC list, then the frequency of kinit failures after a password change
goes way down, but I've measured as high as a 1% fallback rate in the
MIT Kerberos deployment when the master KDC is operational.
I don't think we're currently in a position to simplify out this part of
the initial creds design.  Complexity, once added, is hard to safely
remove.

Agreed. Would MIT consider it sufficient to do a secondary lookup in
this case? A secondary record could have the same format as the primary
record. The cost for this is, of course, a secondary lookup. However,
this only happens in the failure case.

Post by Greg Hudson

Post by Nathaniel McCallum
It is my preference to support a future migration to URI, even if we
grant that such a trasition is vanishingly unlikely.

The main cost here is registering one or more URI schemes, unless we
decide to shoehorn our responses into existing schemes.  See RFC 7595
for the procedures involved.

Well, I'm not sure we need to register it soley for the purposes of an
informational draft. I suspect we'd only need to register if we tried
to push a URI draft through. But you and I already consider this
"vanishingly unlikely."

Post by Greg Hudson
It also makes the DNS responses slightly
larger since the URI scheme (completely predictable if we register our
own) needs to appear in each record.

We are only talking about seven bytes ("krbkdc:") since all the other
contents of the record are required in some form. I'm fine with
removing this if people don't see a value in it. We can always add the
scheme should a serious effort behind the URI record appear.

Post by Greg Hudson

Post by Nathaniel McCallum
Is there any value in having a single query return both kpasswd and
kadmin? If so, then I think separate schemes are desirable.

I don't think there is any value in including kpasswd and kadmin entries
in the same record.  While we do fall back from kpasswd to port-
changed
kadmin when locating kpasswd servers, this is only a provision for
realms with misconfigured DNS.

So then my preference is to avoid a separate scheme.

======================================================================

MIT implements the followin SRV record lookups:
    _kerberos-master.REALM
    _kerberos-adm.REALM
    _kerberos.REALM
    _kpasswd.REALM
    _krb524.REALM

Heimdal supports the following service lookup plugin types:
    locate_service_master_kdc
    locate_service_kadmin
    locate_service_kdc
    locate_service_kpasswd
    locate_service_krb524

However, Heimdal only appears to implement a _kerberos.REALM SRV lookup
internally. Heimdal contains a reference to _kadmin.REALM in an in-tree
copy of a previous attempt at a DNS discovery draft, however, this was
change to "_kerberos-adm" in a subsequent version of the draft:
https://tools.ietf.org/html/draft-ietf-krb-wg-krb-dns-locate-03

It thus seems to me like there is large agreement between MIT and
Heimdal. Thus, I propose the following:

1. Implement all the record names that MIT already supports as TXT.
Using exactly the same semantics that MIT already implements (i.e.
ignoring the weight parameter).

2. Make the format of the TXT record:

    priority:weight:udp:host[:port]
    priority:weight:tcp:host[:port]
    priority:weight:tls:host[:port]
    priority:weight:kkdcp:http://host[:port][/path]
    priority:weight:kkdcp:https://host[:port][/path]

This is isomorphic with the URI record with the exception of a missing
scheme, which could be added later should the desire to use URI emerge.
It also avoids the problem of defining a URI scheme now. I think we can
get away with this by noting that this format isn't technically a URI
even though it closely resembles one.

Thoughts?


_______________________________________________
krbdev mailing list krbdev@

[Simo Sorce]

Post by Nathaniel McCallum
1. Implement all the record names that MIT already supports as TXT.
Using exactly the same semantics that MIT already implements (i.e.
ignoring the weight parameter).
priority:weight:udp:host[:port]
priority:weight:tcp:host[:port]
priority:weight:tls:host[:port]
priority:weight:kkdcp:http://host[:port][/path]
priority:weight:kkdcp:https://host[:port][/path]
This is isomorphic with the URI record with the exception of a missing
scheme, which could be added later should the desire to use URI emerge.
It also avoids the problem of defining a URI scheme now. I think we can
get away with this by noting that this format isn't technically a URI
even though it closely resembles one.
Thoughts?

I like this proposal.
Simo.

[Greg Hudson]

Post by Nathaniel McCallum
Would MIT consider it sufficient to do a secondary lookup in
this case? A secondary record could have the same format as the primary
record. The cost for this is, of course, a secondary lookup. However,
this only happens in the failure case.

We talked about this a bit on IRC. For archival:

* Doing a second lookup for master KDCs is somewhat easier to implement
because that's how the code inside locate_kdc.c works for other
information sources. However:

* Currently, we do the master lookup on success as well as failure
(http://krbdev.mit.edu/rt/Ticket/Display.html?id=7721). Fixing this is
moderately difficult, requiring changes to the krb5_sendto_kdc() and
k5_get_init_creds() contracts. Unless this is fixed, and if we use a
separate lookup for master KDCs, the TXT record feature adds two new DNS
queries for most KDC lookups instead of just one, in realms where TXT
records aren't yet deployed.

* Many realms don't have master KDCs. Representing the absence of
master KDCs with an NXDOMAIN response poses some minor issues: it would
trigger a fallback to SRV lookups unless we take steps to avoid that)
and the TTL for NXDOMAIN caching is global to a DNS zone. Nico notes
that we could allow an empty TXT record to represent the absence of
master KDCs to avoid these issues.

Including master KDCs in the normal KDC RR set could be done by adding
an alphabetical flags field to the TXT record format, where the 'M' flag
indicates a master KDC entry. If we do this, we can store an is_master
value in each struct server_entry, and k5_kdc_is_master() can use that
value to avoid doing the master KDC lookup. We would wind up repeating
the query for the TXT record if we actually do fall back (assuming no
fix for #7721), but we can hope that record is cached by a local resolver.

Post by Nathaniel McCallum
1. Implement all the record names that MIT already supports as TXT.
Using exactly the same semantics that MIT already implements (i.e.
ignoring the weight parameter).

I don't think we need to implement or document krb524 lookups; that's a
vestige. We should be able remove those references from locate_kdc.c
and add a comment in locate_plugin.h that locate_service_krb524 will
never be queried in recent versions.

Post by Nathaniel McCallum
priority:weight:udp:host[:port]
priority:weight:tcp:host[:port]
priority:weight:tls:host[:port]
priority:weight:kkdcp:http://host[:port][/path]
priority:weight:kkdcp:https://host[:port][/path]
This is isomorphic with the URI record with the exception of a missing
scheme, which could be added later should the desire to use URI emerge.
It also avoids the problem of defining a URI scheme now. I think we can
get away with this by noting that this format isn't technically a URI
even though it closely resembles one.

+1 except that I currently favor adding a flags field to indicate master
KDC records.


_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nathaniel McCallum]

Post by Greg Hudson

Post by Nathaniel McCallum
Would MIT consider it sufficient to do a secondary lookup in
this case? A secondary record could have the same format as the primary
record. The cost for this is, of course, a secondary lookup.
However,
this only happens in the failure case.

* Doing a second lookup for master KDCs is somewhat easier to
implement
because that's how the code inside locate_kdc.c works for other
* Currently, we do the master lookup on success as well as failure
(http://krbdev.mit.edu/rt/Ticket/Display.html?id=7721).  Fixing this
is
moderately difficult, requiring changes to the krb5_sendto_kdc() and
k5_get_init_creds() contracts.  Unless this is fixed, and if we use a
separate lookup for master KDCs, the TXT record feature adds two new DNS
queries for most KDC lookups instead of just one, in realms where TXT
records aren't yet deployed.
* Many realms don't have master KDCs.  Representing the absence of
master KDCs with an NXDOMAIN response poses some minor issues: it would
trigger a fallback to SRV lookups unless we take steps to avoid that)
and the TTL for NXDOMAIN caching is global to a DNS zone.  Nico notes
that we could allow an empty TXT record to represent the absence of
master KDCs to avoid these issues.
Including master KDCs in the normal KDC RR set could be done by adding
an alphabetical flags field to the TXT record format, where the 'M' flag
indicates a master KDC entry.  If we do this, we can store an
is_master
value in each struct server_entry, and k5_kdc_is_master() can use that
value to avoid doing the master KDC lookup.  We would wind up
repeating
the query for the TXT record if we actually do fall back (assuming no
fix for #7721), but we can hope that record is cached by a local resolver.

Post by Nathaniel McCallum
1. Implement all the record names that MIT already supports as TXT.
Using exactly the same semantics that MIT already implements (i.e.
ignoring the weight parameter).

I don't think we need to implement or document krb524 lookups; that's a
vestige.  We should be able remove those references from locate_kdc.c
and add a comment in locate_plugin.h that locate_service_krb524 will
never be queried in recent versions.

Post by Nathaniel McCallum
    priority:weight:udp:host[:port]
    priority:weight:tcp:host[:port]
    priority:weight:tls:host[:port]
    priority:weight:kkdcp:http://host[:port][/path]
    priority:weight:kkdcp:https://host[:port][/path]
This is isomorphic with the URI record with the exception of a missing
scheme, which could be added later should the desire to use URI emerge.
It also avoids the problem of defining a URI scheme now. I think we can
get away with this by noting that this format isn't technically a URI
even though it closely resembles one.

+1 except that I currently favor adding a flags field to indicate master
KDC records.

We discussed this on the MIT developer call today and came to a
consensus. The plan looks like this:

1. Implement the following record names as TXT using exactly the same
semantics that MIT already implements (i.e. ignoring the weight
parameter):

    _kerberos-adm.REALM
    _kerberos.REALM
    _kpasswd.REALM

2. The following record names will not be implemented:

    _kerberos-master.REALM
    _krb524.REALM

3. The format of the TXT record is:

    priority:weight:flags:udp:host[:port]
    priority:weight:flags:tcp:host[:port]
    priority:weight:flags:tls:host[:port]
    priority:weight:flags:kkdcp:http://host[:port][/path]
    priority:weight:flags:kkdcp:https://host[:port][/path]

4. The flags field contains zero or more flag characters. Currently,
there is only one flag: M. The M flag indicates that this record refers
to a master KDC.

If you have any objections, please voice them now.
_______________________________________________
krbdev mailing list ***@mit.edu
h

[Greg Hudson]

Post by Nathaniel McCallum
_kerberos-adm.REALM
_kerberos.REALM
_kpasswd.REALM

_kerberos.REALM TXT is currently used to look up the realm of a hostname
(see lib/krb5/os/hostrealm_dns.c), so we should use a different prefix
label, like _krb5kdc or _kdc.

I have no other objections.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Petr Spacek]

Post by Greg Hudson

Post by Nathaniel McCallum
_kerberos-adm.REALM
_kerberos.REALM
_kpasswd.REALM

_kerberos.REALM TXT is currently used to look up the realm of a hostname
(see lib/krb5/os/hostrealm_dns.c), so we should use a different prefix
label, like _krb5kdc or _kdc.
I have no other objections.

Oh wait, I just realized that custom format in TXT RR will break one important
use-case in FreeIPA.

FreeIPA v4.4 is going to have ability to tailor SRV record priorities based on
server & client's location so clients will prefer nearby servers without any
configuration on client side.

For doing so FreeIPA needs to have access to fields 'priority' and 'server
name' in the RR so server name can be mapped to location name & priority
associated with it.

In case of SRV it is easy because RR format is standardized and DNS libraries
can work with it directly.

Custom format inside TXT record will take away this simplicity and every
single system which will want to do something similar will have to implement
parser for the custom format.

For me as an implementer this is major downside of TXT approach.

[Greg Hudson]

Post by Petr Spacek
FreeIPA needs to have access to fields 'priority' and 'server
name' in the RR so server name can be mapped to location name & priority
associated with it.
In case of SRV it is easy because RR format is standardized and DNS libraries
can work with it directly.

SRV is not really an interesting comparison unless your viewpoint is
that MS-KKDCP transport discovery just shouldn't be implemented.

If we used URI you would have easy access to the weight (assuming your
DNS library implements the URI RR type), but not to the server name,
since we would be using a Kerberos-specific URI scheme.

Post by Petr Spacek
Custom format inside TXT record will take away this simplicity and every
single system which will want to do something similar will have to implement
parser for the custom format.
For me as an implementer this is major downside of TXT approach.

Sure. Structure is good for consumers who want to know about it,
especially if they can delegate the understanding of that structure to a
library. Structure is bad for producers who want to know as little as
possible, or for getting through middle-boxes which habitually reject
structure tags they don't understand. It's a trade-off.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Petr Spacek]

Post by Greg Hudson

Post by Petr Spacek
FreeIPA needs to have access to fields 'priority' and 'server
name' in the RR so server name can be mapped to location name & priority
associated with it.
In case of SRV it is easy because RR format is standardized and DNS libraries
can work with it directly.

SRV is not really an interesting comparison unless your viewpoint is
that MS-KKDCP transport discovery just shouldn't be implemented.
If we used URI you would have easy access to the weight (assuming your
DNS library implements the URI RR type), but not to the server name,
since we would be using a Kerberos-specific URI scheme.

Right, I should have mentioned URI.

With URI we could end up with a regex extracting first name after scheme
specification or something simple like that. That would be generic and safe
enough for URI (keep in mind that failure to match host name means no change
so nothing seriously bad happens).

Unfortunately simple universal regex would not work for TXT RR because even if
we found a name in it we would have to know what bytes have to be changed -
again this requires more knowledge than should be stuffed in a DNS library.

Post by Greg Hudson

Post by Petr Spacek
Custom format inside TXT record will take away this simplicity and every
single system which will want to do something similar will have to implement
parser for the custom format.
For me as an implementer this is major downside of TXT approach.

Sure. Structure is good for consumers who want to know about it,
especially if they can delegate the understanding of that structure to a
library. Structure is bad for producers who want to know as little as
possible, or for getting through middle-boxes which habitually reject
structure tags they don't understand. It's a trade-off.

My point is that URI has better trade-off in this respect and that TXT is
making integration unnecessarily complex and forces implementers to add
Kerberos-specific hacks to otherwise generic solution.

[Matt Rogers]

Post by Greg Hudson

Post by Nathaniel McCallum
_kerberos-adm.REALM
_kerberos.REALM
_kpasswd.REALM

_kerberos.REALM TXT is currently used to look up the realm of a hostname
(see lib/krb5/os/hostrealm_dns.c), so we should use a different prefix
label, like _krb5kdc or _kdc.
I have no other objections.

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

[Greg Hudson]

Post by Matt Rogers
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[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-***@mit.edu [mailto:krbdev-***@mit.edu] On Behalf Of Greg Hudson
Sent: Wednesday, June 1, 2016 11:33 AM
To: Matt Rogers <***@redhat.com>
Cc: ***@mit.edu
Subject: Re: Kerberos transport DNS record design

Post by Matt Rogers
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Petr Spacek]

Post by Greg Hudson

Post by Matt Rogers
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.

Right now TXT usage is not sufficiently specified:

1. Should multiple KDCs be specified as multiple RRs with one character string
OR as multiple character strings in one RR? (RFC 1035 section 3.3.14)
- Consequently:
What happens if an attacker sends the other possible encoding?

2. But wait, what is the TXT's encoding? TXT is just a binary blob.
- Consequently:
What happens if there is binary 0 in the middle of TXT data? ...
Is limitation to 255 octets in TXT a problem?

3. What about IDNA? Unicode? Or just space, slash or colon in the URL? How it
gets encoded?

I'm sure I missed something else which is under-specified. Again, proper URI
record would solve all this.


4. Is it a good idea to require IP addresses in the TXT? It means that IP
address change needs to be done on one more place (it is not sufficient to
change A/AAAA record anymore) which adds maintenance burden.

Post by Greg Hudson
* 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.

Is 26 flags enough or do we want 26*2? :-)


Getting back to original discussion, I still believe that TXT usage is a bad
idea for several reasons.


a) First thing is due diligence:
Did someone test adding URI records before jumping on TXT?
Was an support ticket opened if it did not work?
What was the answer?
Where are the data? :-)

I've opened couple tickets for my DNS domains I personally own. First answer I
got is "let us know what records we can add for you", waiting for an answer
from others.

Of course, it could be much quicker (and with higher negotiating power) if the
tickets were opened using company account but somebody with appropriate
credentials would have to do it ... and this requires interest in getting hard
data.



b) IMHO we should not jump to TXT without an attempt to get URIs added.
Jumping right to TXT without hard data is a wrong idea for reasons explained in
http://mailman.mit.edu/pipermail/krbdev/2016-June/012604.html
http://mailman.mit.edu/pipermail/krbdev/2016-June/012608.html

It would be naive to think that the record will be parsed only by Kerberos
libraries and nothing else. Parsing will not happen in one place anyway
because DNS admins (humans)/IPA framework/user interface code will hardly call
krb5 library to parse it.

For this reason it is very illusory to think that not using standard
pieces will not save time.

It just makes it harder for other components of DNS system to tailor the
response as needed because it is impossible to use standard DNS
parsers.



c) Even more importantly, it makes it harder for users to use the thing
because they will have to learn a new syntax and deal with multi-part TXT
records, which could be a UI problem too when we are at it.
E.g. I did not see ability to add multi-part TXT records in Azure:
https://azure.microsoft.com/en-us/documentation/articles/dns-operations-recordsets/



d) Speaking of middle-boxes and URI filtering, Netalyzr study from 2011 [1]
shows this:
- 98.3% of clients is able to resolve TXT records
- 97.2% of clients is able to resolve made-up type 169 (not allocated
at all)

URI should be somewhere in between because it is standardized. Also,
5 years passed and a lot of networks could have been patched.

Considering all this I do not think that URI blocking is relevant
problem.

[1] https://www.icsi.berkeley.edu/icsi/publication_details?n=3112

[Matt Rogers]

Post by Nathaniel McCallum

Post by Greg Hudson
* 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

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.

+1

Post by Nathaniel McCallum

Post by Greg Hudson
  - 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
priority:weight:krbkdc:udp:host[:port]
priority:weight:krbkdc:tcp:host[:port]
priority:weight:krbkdc:tls:host[:port]
priority:weight:krbkdc:kkdcp:http://host[:port][/path]
priority:weight:krbkdc:kkdcp:https://host[:port][/path]

No particular preference here, so this format is fine to me.

Post by Nathaniel McCallum

Post by Greg Hudson
  - 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.

Post by Greg Hudson
* 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.

Post by Nathaniel McCallum
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

[Petr Spacek]

Post by Greg Hudson
Currently we can map from a Kerberos realm name to the TCP and/or UDP
addresses of a KDC, kpasswd, or kadmind server. Several of us have been
discussing how to best extend that mechanism to include MS-KKDCP, and at
the same time minimize the number of DNS lookups required to contact a
realm without configuration.
We had been planning to use the URI record type, but after a recent
round of discussion, we don't think it's likely that popular DNS hosting
providers will allow customers to create URI records (since it seems
like no one else is using them). Some middle-boxes would also block DNS
queries for URI records. That problem would be even worse if we create
a new record type. So, we are planning to use the TXT record type. It
seems unlikely that we can standardize on a TXT record through the IETF
(except perhaps as an informational RFC), but it seems like the only
deployable option for individuals and small organizations.
If we use the TXT record type, we have to define the payload format,
which is the primary subject of this thread. The payload must
* Priority, because DNS records are unordered
* Transport type--currently one of TCP, UDP, and MS-KKDCP
* For the TCP and UDP types, the hostname and optional port
* For the MS-KKDCP type, the proxy URL
The format must be extensible to future transport types, including
ones that use TCP, UDP, or HTTP in different ways. Examples could
include Heimdal's HTTP proxy protocol or RFC 6251 (Kerberos over TLS).
* Do we want to include weights as well as priorities? I think weights
are unnecessary complexity, even just as an optional field in the
format, but I seem to be in the minority.
* Do we want to include master KDCs in the same query as normal KDCs, or
should they be in a separate record? (Master KDCs are used as a
fallback by the MIT client code when we receive a KDC error which
could have resulted from out-of-date data due to propagation delays.)
- If we do communicate master KDCs in the same record, should it be
possible to exclude a master KDC from the normal server list (so
that it is only contacted if a normal KDC returns an error), or is
it sufficient to be able to assign master KDCs a low priority?
* 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
- 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?
- If we do create new URI schemes, should we use use separate schemes
for krb5/kpasswd/kadmin, or use the same scheme since we already
know the application protocol going in?
- Should we use fragment identifiers (#suffix) to indicate master-ness
and/or the transport type, or should we use a prefix?
If we don't restrict ourselves to an isomorphic-to-URI payload format,
we still have to decide whether and how to represent master KDC
entries, but the other concerns largely go away.
* 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?

For the record, opinions of DNS gurus from dnsop list can be found in dnsop
archives:
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize this if you try it.

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.


Pick an answer which suits you the best :-)

[Matt Rogers]

Post by Petr Spacek
For the record, opinions of DNS gurus from dnsop list can be found in dnsop
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html
Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize this if you try it.
Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.
Pick an answer which suits you the best :-)

Since there is encouragement for URI here it seems like moving forward
with the URI is the right thing to do. If the hosting
provider/middle-box issue is something that we do not need to worry
about, is there still a downside to settling on the URI right now and
standardizing it in parallel? From the code standpoint there will not
be much difference vs. the TXT RR.

[Petr Spacek]

Post by Matt Rogers

Post by Petr Spacek
For the record, opinions of DNS gurus from dnsop list can be found in dnsop
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html
Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize this if you try it.
Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.
Pick an answer which suits you the best :-)

Since there is encouragement for URI here it seems like moving forward
with the URI is the right thing to do. If the hosting
provider/middle-box issue is something that we do not need to worry
about, is there still a downside to settling on the URI right now and
standardizing it in parallel? From the code standpoint there will not
be much difference vs. the TXT RR.

It would be good to get some actual data about URI feasibility.

Are you able to get your DNS provider to add an URI record? Do you have an
account on Amazon/Azure/others and ability to open a ticket?

That would help to get hard data and after that we would have something to
base decisions on.

[Matt Rogers]

Post by Petr Spacek

Post by Matt Rogers

Post by Petr Spacek
For the record, opinions of DNS gurus from dnsop list can be found

in dnsop

Post by Matt Rogers

Post by Petr Spacek
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html
Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize this if you try

it.

Post by Matt Rogers

Post by Petr Spacek
Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.
Pick an answer which suits you the best :-)

 
Since there is encouragement for URI here it seems like moving

forward

Post by Matt Rogers
with the URI is the right thing to do.  If the hosting
provider/middle-box issue is something that we do not need to worry
about, is there still a downside to settling on the URI right now

and

Post by Matt Rogers
standardizing it in parallel?  From the code standpoint there will

not

Post by Matt Rogers
be much difference vs. the TXT RR. 

It would be good to get some actual data about URI feasibility.
Are you able to get your DNS provider to add an URI record? Do you have an
account on Amazon/Azure/others and ability to open a ticket?
That would help to get hard data and after that we would have
something to
base decisions on.

With everything considered we've agreed to go forward with the URI
record. I've posted updates to the Wiki (http://k5wiki.kerberos.org/wik
i/Projects/KDC_Discovery) and the implementation is underway at https:/
/github.com/krb5/krb5/pull/481

Matt
_______________________________________________
krbdev mailing list ***@mit.edu
http