DNS SRV Records

[Ken Raeburn]

On Thursday, Jan 8, 2004, at 17:10 US/Eastern, Daniel Henninger wrote:
>>> _kerberos			TXT	"EOS.NCSU.EDU"
>> Yes.  Note that there are security issues here, and other mechanisms
>> are preferred.  (Unless you've got secure DNS set up, that is.)
> The domain to realm mapping has security issues, or -all- of this does?
>

The domain to realm mapping, if spoofed, can trick a client program 
into authenticating to the wrong realm.  If the appropriate principals 
exist in that other realm (perhaps set up by a less than scrupulous 
administrator), and the address record lookup is similarly spoofed (or 
the traffic is intercepted, or anything similar), then the client would 
quietly authenticate (successfully) to the wrong server, the user would 
send his private data, etc.

With the other SRV records, if the software is implemented properly, 
all that spoofed records can do is cause a denial of service, and 
generally it would have to be an active attack.

> But theoretically we don't like normal clients "bothering" our master.
> (just a decision we made...)  That's why I left those out.

Ah, yes, that's fine too.  At MIT, at least, we haven't noticed client 
exchanges being a significant load, so we don't worry about it.  You 
could also use SRV record priorities (which we support) and weights 
(which we don't, yet) to express other policies, like using the master 
if no answer is heard from the slaves, or (if you want to implement 
weights, hint hint :-) sending a much smaller fraction of the traffic 
to the master than to any of the slaves, etc.

>> So, yes, it means TCP Kerberos service isn't supported.  But Windows
>> clients aren't the only ones that look for TCP service; MIT's got the
>> code too.
>
> Does 1.2.8 support that?  (that's what we're running right now, I 
> haven't
> decided to delve us into the 1.3 series just yet)  I was to understand
> from some changelogs that tcp support there was a 1.3 thing.
>

Oh.  Yeah, I think it was 1.3 when it went in.

> Sweet!  Let me make sure I understand the realm mappings 100%.  My
> understand is that a default_realm under libdefaults makes it so the
> domain -> realm mappings aren't that necessary.  IE, if I'm on
> ghidora.unity.ncsu.edu, and my krb5.conf says my default_realm is
> EOS.NCSU.EDU, then I don't need the mapping to say unity.ncsu.edu =
> EOS.NCSU.EDU... right?
>

The default_realm entry applies for the local host, not to all hosts in 
the domain containing the local host.  So yes, you'd still need that 
mapping.

And, to make it clear, the DNS records may have to go into different 
domains.  For example, if your domain is unity.ncsu.edu and your realm 
name is EOS.NCSU.EDU (for both krb5 and krb4), as above, then the names 
of the resource records would be:

   _kerberos.ghidora.unity.ncsu.edu  (TXT)
   _kerberos.unity.ncsu.edu (TXT)
   _kerberos._udp.eos.ncsu.edu (SRV)
   _kerberos-iv._udp.eos.ncsu.edu (SRV)
...

Ken