Re: Turning off hostname canonicalisation

[Sam Hartman <hartmans@mit.edu>]

>>>>> "Jeffrey" == Jeffrey Altman <jaltman@MIT.EDU> writes:

    Jeffrey> Andrew: MIT has already implemented this functionality.
    Jeffrey> We added

    Jeffrey> [libdefaults] rdns = {no, yes}

    Jeffrey> It currently defaults to "on" but can be turned off in
    Jeffrey> the profile.

    Jeffrey> Jeffrey Altman



    Jeffrey> Andrew Bartlett wrote:
    >> As part of our effort to get kerberos working really well in
    >> Samba4, I'm interested to turn off hostname canonicalisation,
    >> because it isn't required in AD realms, it doesn't make much
    >> sense anyway for netbios names and DNS is so often broken on
    >> real networks.
    >> 
    >> Rather than just rip out the code (in our modified heimdal
    >> snapshot), I was looking at instead using a krb5.conf config
    >> option, and hoped that I might get some consensus as to how
    >> this should be done, between the two projects that share the
    >> /etc/krb5.conf file (and have done so very well, I get
    >> surprisingly little pain from this).
    >> 
    >> I'm thinking along the lines of: [libdefaults]
    >> hostname_canonicalise = no
    >> 
    >> This would prevent the krb5 libs doing hostname lookups to
    >> obtain a fully-qualified hostname.
    >> 
    >> For compatibility I assume it would be 'yes' by default, but
    >> Samba would set it to no in the krb5_init_context routines.
    >> 
    >> Does this sound sane?
    >> 
    >> Andrew Bartlett
    >> 
    >> 
    >> ------------------------------------------------------------------------
    >> 
    >> _______________________________________________ krbdev mailing
    >> list krbdev@mit.edu
    >> https://mailman.mit.edu/mailman/listinfo/krbdev
    Jeffrey> _______________________________________________ krbdev
    Jeffrey> mailing list krbdev@mit.edu
    Jeffrey> https://mailman.mit.edu/mailman/listinfo/krbdev

This is broken.  If we're going to add a knob it should implement the
RFc 4120 behavior not some behavior between the current code and 4120.

I don't think we have shipped this yet have we?