DNS lookups and krb4 Support

[Derek Atkins]

Sorry for coming into this so late.  Sam asked me about a month ago to
look into this thread from a DNS point of view.  That request got put
onto my queue and then I got hosed, so my appologies for re-opening
this topic.

>From a DNS point of view, each service should have its own SRV record,
and applications should not necessarily infer anything about one
service from the existence or non-existence of another service.  In
other words, the existence of "_kerberos._udp.example. SRV ..." should
not imply anything about the existence (or non-existence) of krb4 or
krb524 support).  In other words, what MIT krb5 does now (assuming
krb4 from the existence of krb5) is wrong.

Unfortunately because MIT Kerberos has done it wrong, going forward
there is no way to fix it completely in a backwards-compatible way.
There may be people that are depending on the broken methods, and
that means there is no way to fix it...

The best you can do is what Ken suggests below (which is why I
included his email in this response).  Going forward I would recommend
you have a 1:1 mapping of service -> SRV record.  You can then use the
SRV records to assert the existence (or non-existence) of a service.

-derek

Ken Raeburn <raeburn at MIT.EDU> writes:

> An interesting tidbit about the SRV RR specification that people may
> not be aware of is that it includes a means of indicating that a
> service is not provided; you simply provide exactly one RR, with a
> target of ".".
> 
> (I don't think we explicitly implement it in our code, but I suspect
> the address lookup will simply result in zero addresses, causing an
> adequate error message to be produced.)
> 
> So, a krb5 realm that provides no krb4-related services could choose
> to indicate that with:
> 
>    _krb524._udp.example.com.     SRV   0 0 0 .
>    _kerberos4._udp.example.com.  SRV   0 0 0 .
> 
> or something like that.
> 
> The absence of any records at all is a lack of information.  In that
> situation, it may be reasonable to try heuristics like looking up the
> krb5 service and munging the port numbers (or not), or trying the
> hostname "kerberos.$REALM" -- but we should never document those as a
> recommended approach to administration.
> 
> We would just need to make sure that, if the _kerberos4 record exists
> and lists ".", we don't go on to use the _kerberos information.
> 
> I think it might be useful to tweak the config file handling code,
> too, so that we have a way of indicating that the service isn't
> available, and fallback heuristics should not be used.
> 
> Ken
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available