Domain-to-realm matching vs MIT krb5.conf

[grawity]

Describe the bug

Commit https://github.com/dotnet/Kerberos.NET/commit/85eca6c936312a39078873b6a05bab39915ec01b added support for domain-to-realm mappings.

If I understand correctly, the project seems to try to be compatible with MIT/Heimdal's [domain_realm] section – in this case though the matching ends up being incompatible. Specifically this comment:

                // bar.foo.net matches explicitly
                //      bar.foo.net matches
                //      baz.foo.net does not match
                //      baz.bar.foo.net does not match

But in MIT's krb5.conf, this does match not only the specified domain but also everything under it. As noted in commit https://github.com/krb5/krb5/commit/8f5ce824012f2caab6770df464f096c38dc4cb2e, the documentation indeed used to say otherwise, but wasn't correct.

This fixes a long-standing documentation bug where we claimed that a domain_realm mapping for a host name would not affect entries under that domain name. The code has always had the behavior where a host name mapping implies the corresponding domain name mapping, since the 1.0 release.

Expected behavior

A domain-to-realm mapping for bar.foo.net should also match quux.bar.foo.net.

[SteveSyfuhs]

"Try" is about right, though we do diverge from implementation from time to time where we break for compatibility with Windows or what the author (usually me) thinks is really the better mechanism. In this particular case it seems most logical that things that start with a period means inclusive of all values below, and anything beginning with a name is an exact match. It seems really weird that d.c.b.a would match c.b.a.

Is this a common scenario that krb5 users end up relying on?