DNS lookups and krb4 Support
jaltman at columbia.edu
Sat May 31 14:37:06 EDT 2003
I am going to answer the last question first because that one is actually the easiest one to answer.
Sam Hartman wrote:
> Another related question: if we do end up supporting multiple DNS
> records, does the krb524 service belong to the krb5 KDC or the krb4
> KDC? I believe having a third record for krb524 may be the wrong
The rule for DNS SRV records is that each "service" / "transport"
combination is supposed to have its own record.
This means that the krb524 service should have its own DNS SRV record.
>When DNS support was added to MIT Kerberos the same srv record tag was
>used to look up both krb5 and krb4 KDCs.
>Now, when we are discouraging new realms from deploying krb4 support,
>we run into a problem. We need to know whether a realm supports krb4
>before sending krb4 requests to that KDC. A krb5 KDC may (and our
>code now defaults to this behavior) drop krb4 packets on the floor
>without answering them at all.
>So, attempting to engage in krb4 protocol transactions with a
>krb5-only KDC may produce timeouts for the user. We sometimes get
>people complaining about log messages and other events as well.
>According to Assar, Heimdal and Kerberos4-kth solve this problem by
>using a different service tag for krb4 than the one used for krb5.
>We could adopt that approach. However, doing so would cause behavior
>that has worked in previous versions of our code to suddenly stop
>working. In particular, people who have only published the krb5 DNS
>records but who use krb4 would suddenly start failing.
>I do not like this option, so I am hoping someone on this list can
>come up with something better. But it does seem like a strong
>requirement that we be able to know before sending to a KDC whether
>that KDC will support krb4 or not.
I have several ideas that might be applicable. A DNS SRV record of
without an accompanying
record could be interpreted to mean Kerberos 5 only.
Another idea could involve the publication of a negative DNS SRV record:
We would need to have a discussion with the DNS community to see what is
Whatever we do will always have the problem of the existing installed
base considering _kerberos._udp.<domain> to mean both Kerberos 4 and
Kerberos 5. Therefore, anything we would want to do would require
deprecating _kerberos and replacing it with _kerberos4 and _kerberos5.
Unfortunately, this would do nothing to solve the problem for existing
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3590 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20030531/39b0cd11/attachment.bin
More information about the krbdev