Re: [kitten] Finding Kerberos Realm Descriptors in secure DNS

[Viktor Dukhovni <[e-mail]>]

On Tue, Sep 15, 2015 at 09:41:12AM +0200, Rick van Rein wrote:

> Hi Viktor,
> 
> > Text strings used to be handy for realm names in DNS when associated
> > SRV records were plausibly optional.  These days, the REALM *should*
> > be a DNS name.
> 
> If that's not MUST then I don't think it's a safe assumption to make.

The proposal need not support all legacy options.  Folks who want
non-DNS name realms can manage the mapping outside DNS.

> > Therefore, a simpler design would be:
> >
> >     ; Realm mapping per-host reduces lookup latency
> >     ;
> >     _kerberos.host.name.example.com. IN PTR EXAMPLE.COM.
> 
> The value of PTR is a <domain-name> rather than a binary <character-string>,
> which makes it case-insensitive and I wouldn't be surprised if some name
> server mangled the case of PTR records to all-lowercase.

No, it is not "case-insensitive".  The value of PTR records is
returned verbatim by nameservers.  What's case insensitive is
lookups derived from that name when you use it in a query string.

> Also, the trailing dot is not the only form that may be used;
> there can be relative names.

You're confused.  DNS wire format carries fqdns, as a sequence of
length-encoded labels, with the last length set to 0 (there is no
trailing ".", there's an empty label).  There might be "relative"
names in zone files, but none will appear on the wire.

> And, you are using PTR in forward DNS, which may upset people.

There's no such thing as "forward" vs. "reverse" DNS.  All zones
are just zones.  There's nothing magic about in-addr.arpa or
ip6.arpa.  Plus there are frequently CNAMEs from these into other
zones allowing users to manage their own PTRs.

> Finally, the PTR record already has its meaning, and that is not the one
> we have in mind.

It it *exactly* the meaning you have in mind.  A DNS name that is
not an alias.  A pointer to another place in the DNS.

> I've initially proposed overloading TXT and that gave strong responses to
> instead register a new RRtype, and nobody on DNSEXT is questioning that
> change.  I therefore propose to not follow your idea.  It made me smile
> though, because it is an interesting find.

You haven't seen my battle scars fighting broken nameservers that
block TLSA queries.

Try the following experiment:

    $ dig +short -t mx disa.mil | sort -n
    0 pico.disa.mil.
    5 indal.disa.mil.
    10 dnipro.disa.mil.

    $ dig +short -t a pico.disa.mil
    214.36.3.4

Now the fun bits, first a PTR lookup, which works as expected:

    $ dig +noedns +noall +comment +ans +nocl +nottl -t ptr pico.disa.mil
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37990
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Now a TLSA lookup:

    $ dig +noedns +noall +comment +ans +nocl +nottl -t tlsa pico.disa.mil
    ... long delay ...
    ;; connection timed out; no servers could be reached

Now some brand new RRtype:

    $ dig +noedns +noall +comment +ans +nocl +nottl -t TYPE12345 pico.disa.mil
    ... long delay ...
    ;; connection timed out; no servers could be reached

Many firewalls mistakenly filter "exotic" DNS queries.  The KREALM
RRtype will encounter unnecessary friction.

With the PTR record, UTF-8 labels in Kerberos realms can be converted
to A-labels in zone files and on the wire, with the client mapping
them back to U-labels to reconstruct the realm name, and using the
A-labels directly to locate SRV records, ...

Kerberos realms in DNS should be DNS names, the PTR record will
work much better, is supported by existing zone management tools,
and is not blocked by firewalls.

-- 
	Viktor.