Correct DNS Behavior

Ken Raeburn raeburn at MIT.EDU
Thu May 31 13:48:13 EDT 2007

On May 31, 2007, at 12:31, Michael B Allen wrote:
> My code can't find the KDC on a particular customer's network. The
> problem is DNS.
> The DNS communication looks like the following:
> C: SRV _kerberos._udp.EXAMPLE.COM
> S: No such name
> C: SRV _kerberos._tcp.EXAMPLE.COM
> S: 3 answer records:
>      krb1.EXAMPLE.COM
>      krb2.EXAMPLE.COM
>      krb3.EXAMPLE.COM
>    1 authority:
>      dns2.EXAMPLE.COM
>    1 additional:
>      A dns2.EXAMPLE.COM
> S: No such name
> S: No such name
> S: No such name
> Then the client gives up.
> [All queries have recursion desired on. The exact dialog involves a
> larger number of hosts and of course the names have been changed but I
> believe the normalized dialog above accurately
> represents the problem.]
> I want to fix this but I don't know what the correct behavior is in
> this scenario.
> Can someone tell me why this failed and what the correct behavior  
> should be?

Usually the client is set up to talk to a recursive resolver that'll  
talk to the other nameservers.  It sounds like it's not doing that,  
or it's getting the wrong results.

A couple things you might check just in case, though they're probably  
not the problem: (1) IPv6-only KDCS?  (2) Does  
really have the KDC addresses?

> My feeling is that the client is responsible and that it should
> simply repeat the query against the authority dns2.EXAMPLE.COM.

If the local nameserver is iterative and expects the client DNS code  
to query the next server, perhaps, but (1) I've never run into a  
configuration that was intentionally set up that way for random  
users' end systems to talk to, and (2) returning "no such name" is  
probably not the right way to implement it.


More information about the Kerberos mailing list