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

[Rick van Rein <[e-mail]>]

Hi Nico,

> Nico Williams <mailto:[e-mail]>
> 14 September 2015 17:28
>

> I don't think that the zone apex is necessarily a good place to stop.

I've seen  lots of these cautious remarks.  The alternative might to not
iterate, but other than that I see no clear point.

I picked the zone apex, marked by the "start of authority" RR, because
it is a known breaking point for DNSSEC security because it's where
DNSKEYs get changed, and control over them.

We've been talking about this before, and it always seems to end up in
not having a conceptually clear, and query'able place where to stop
upward iteration on security grounds.  What this proposal is saying is
that in case your parent domain contains proper realm records, you will
have to copy them in the lower one, thereby stating that the owner of
the child zone agrees.

> DNS delegation does not imply as much as you make it out to.

Wait -- I'm talking of DNSSEC delegation.  The change of DNSKEYs and
thereby of the control over a zone's security.

> I'm not
> sure what the best thing to do here is. I'll think about it. But I'm
> quite certain that DNS zone cuts are not the right thing to use.
>
If you know a better place then I'm listening.  If it's going to be a
philosophical debate that stops us getting this important facility then
I'm really interested in (relatively clean) short cuts, including a
construct for DNS zones that may not be part of the original DNS design,
that was strengthened by the DNSSEC design but that was nevertheless
ever fully spelled out.

> Also, your method is:
>
> | 5. When the type bit map in the secure denial indicates the presence
> | of a SOA record under the current name, then no further
> | iterations are possible, and the algorithm ends in failure.
>
> which fails if there are KREALM RRs for some things but not realm.
>
Yes, and that's deliberately, although we could discuss advantages of
changing it.

If you start defining KREALM RRs you should put all those in place that
belong there, so you don't need to continue iterating after you found
the first KREALM RRset.

> I think the "key" part of the KREALM RR RDATA may be best as an
> _-prefixed label in the qname (not least as it reduces response size, at
> the expense of increasing the number of queries when the client needs
> more than one key's RDATA, but this is fine I think).
>
I completely agree, and am indeed formulating that now in -05.

> Then there'd not be much difference between a KREALM RR and a TXT RR...

There's an incredible difference in semantics, that have been defined
for KREALM and not for TXT.  Also, the DNS folk really don't like
overloading TXT with structured / meaningful / interpreted data, they
were the ones who drove me to define a new RRtype.

Cheers,
 -Rick