DNS lookups and krb4 Support

[Jeffrey Altman]

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
> approach.

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

  _kerberos._tcp.<domain>

without an accompanying

  _kerberos._udp.<domain>

record could be interpreted to mean Kerberos 5 only.

Another idea could involve the publication of a negative DNS SRV record:

  _kerberos4._no.<domain>

or
 
  _no_kerberos4._udp.<domain> 

We would need to have a discussion with the DNS community to see what is 
best. 

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 
clients.

- Jeff


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3590 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20030531/39b0cd11/attachment.bin