Subject: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt

From: Rick van Rein <[email-masked]>
Date: Thu, 03 Sep 2015 17:36:08 +0200

Hello,

I am working on an I-D that allocates a new RRtype in DNS, named
KREALM.  This RR is meant to store Kerberos realm descriptions in DNS;
this has hitherto been desired but impossible to do securely, but
nowadays the broad acceptance of DNSSEC permits this facility.

Please let me know if you have any feedback or questions!

Cheers,

Rick van Rein
for ARPA2.net

> A new version of I-D, draft-vanrein-dnstxt-krb1-02.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:		draft-vanrein-dnstxt-krb1
> Revision:	02
> Title:		Kerberos Realm Descriptors in DNS (KREALM)
> Document date:	2015-09-03
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/internet-drafts/draft-vanrein-dnstxt-krb1-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-dnstxt-krb1/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-vanrein-dnstxt-krb1-02
>
> Abstract:
>    This specification defines methods to determine Kerberos realm
>    descriptive information for services that are known by their DNS
>    name.  Currently, finding such information is done through static
>    mappings or educated guessing.  DNS can make this process more
>    dynamic, provided that DNSSEC is used to ensure authenticity of
>    resource records.
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Sep 2015 08:14:10 +1000

If you only want the AD bit to be returned then set AD=1 in the
query not DO=1.  See RFC 6840.  Modern versions of DiG do this by
default.  If the resolver or the path to it is not trusted then you
need to specify DO=1 and perform local validation as you can't rely
on the AD bit.

Don't put the base64 in quotes.

Do specify that the base64 encoding may be broken up by white space
and may be over multiple lines using the standard DNS mechanisms
for doing this.  There is no need for it to be a single lexographic
token.  This needs to be clear as registrars stuffed up DS handling
by only coding for a single lexographic token in DS despite it being
specified as allowing multiple tokens.  Add some examples where the
base64 is split into multiple tokens.

Mark

In message <[email-masked]>, Rick van Rein writes:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Rick van Rein <[email-masked]>
Date: Fri, 04 Sep 2015 08:38:23 +0200

Hi Mark / others,

Thanks for your reading & commenting!

As for base64, I was also considering to adopt the hexadecimal notation
used for Unknown RRtypes [RFC 3579]; ASN.1 data is quite readable in
hexdump form, and absolutely not in base64 form.

Do you have any ideas if that would be considered silly or awkward?

> need to specify DO=1 and perform local validation as you can't rely

Thanks for pointing that out, I was indeed following older specs. 
Changed for -03:

   To give one possible implementation, a Kerberos client may send DNS
   queries with the Authentic Data (AD) bit set to enable DNSSEC
   [Section 5.7 of [RFC6840]], and require that the Authenticated Data
   bit is set in the response to indicate [RFC3655] the Secure state for
   answer and authority sections of the response.  When the DNS traffic
   to and from the validating resolver is protected, for instance
   because that resolver is reached over a loopback interface, then the
   Kerberos client has implemented the requirements for Secure use of
   the answer and authority sections in DNS responses.

> Don't put the base64 in quotes.

I changed the examples accordingly in -03.

> base64 is split into multiple tokens.
Added to -03

   [...]  The base64-represented data may be interspersed with white
   space, including even line breaks if the usual DNS zone file notation
   with parenthesis is used.

I also demonstrated the line breaks in an example:

   www.example.com.  IN KREALM ( ME8xTTAOFgdzZXJ2aWNlDANmdHAwDxYH
   c2VydmljZQwESFRUUDAUFgVyZWFsbQwL RVhBTVBMRS5DT00wFBYFcmVhbG0MC0VY
   QU1QTEUuT1JH )

Thanks!
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Sun, 06 Sep 2015 16:08:45 +0200

Hello DNSEXT,

FYI, I have updated mu draft to follow up with Mark Andrews' remarks. 
One more DNS-related change is that the reliance of the type bit map in
NSEC/NSEC3 now has a fallback procedure of explicitly requesting SOA if
a client cannot get hold of the denial itself.

The new version is https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1-03

The changes are:
* DNSEXT: RFC 6840: Set AD=1 instead of DO=1 in the query
* DNSEXT: base64 without quotes and possibly with whitespace and std
line breaks
* Made SOA through type bit maps an optional path, explicit SOA query is
OK too
* Introduced the "admin" tag to specify administrator principal names
* Clarified references from non-home records to srv + home records

Thank you,
  -Rick

---

From: Rick van Rein <[email-masked]>
Date: Fri, 11 Sep 2015 10:58:18 +0200

DNS RRTYPE PARAMETER ALLOCATION REQUEST

   A. Submission Date: September 11, 2015.

   B.1 Submission Type:  [X] New RRTYPE  [ ] Modification to RRTYPE
   B.2 Kind of RR:  [X] Data RR  [ ] Meta-RR

   C. Contact Information for submitter (will be publicly posted):
      Name: Rick van Rein              Email Address: [email-masked]
      International telephone number: +31.53.4782239
      Other contact handles: Haarlebrink 5, 7544 WP  Enschede, The
Netherlands

   D. Motivation for the new RRTYPE application.

      Kerberos lacks a mechanism to find a realm name for a given domain
name
      or host name.  This was never defined due to insecurity of DNS.  With
      DNSSEC broadly deployed, we can now safely lookup realm
descriptions for
      DNS names, and this RRtype captures such realm descriptions.  The new
      facility can help to realise new Kerberos use cases such as
Internet-wide
      realm crossover.

   E. Description of the proposed RR type.

      https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1

   F. What existing RRTYPE or RRTYPEs come closest to filling that need
      and why are they unsatisfactory?

      TXT might have worked, but would require "educated guessing" on the
      semantics (not ideal from a security perspective) and is advised
      against by DNS experts; a new RRtype was suggested in its place.

   G. What mnemonic is requested for the new RRTYPE (optional)?

      KREALM (short for Kerberos Realm Descriptor)

   H. Does the requested RRTYPE make use of any existing IANA registry
      or require the creation of a new IANA subregistry in DNS
      Parameters?  If so, please indicate which registry is to be used
      or created.  If a new subregistry is needed, specify the
      allocation policy for it and its initial contents.  Also include
      what the modification procedures will be.

      From the 04 version of the I-D we quote:

       This specification defines a new "Resource Record (RR) Type", to be
       registered in the IANA registry of Domain Name System (DNS)
       Parameters".  The name of the RRType is KREALM, its value is TBD1 and
       its meaning is "Kerberos Realm Descriptor".

       This specification establishes a new registry with IANA, whose
       entries are subject to expert review and whose definition must be
       described in a publicly available specification.  The new registry
       will be known as the "Kerberos Realm Descriptor Tag Registry".  Each
       entry must provide a Yes/No flag to indicate if the tag is a Home
       Tag, meaning that it may only be interpreted as part of Home Records.

       The initial entries for this new registry introduced by this
       specification are:

                    +----------+-----------+-----------------+
                    | Tag name | Home Tag? | Definition      |
                    +----------+-----------+-----------------+
                    | realm    | No        | [TBD:THIS-SPEC] |
                    | service  | No        | [TBD:THIS-SPEC] |
                    | admin    | Yes       | [TBD:THIS-SPEC] |
                    +----------+-----------+-----------------+

       Tag names are case-sensitive.  Registration of new tags is subject to
       expert review, and a specification must be created as part of its
       definition.

       DISCUSS: Suggestions on the submission process for new tags are
       requested.

       In addition to the foregoing, tag names starting with "x-" are
       reserved for local and experimental use, for which registration is
       neither possible nor required.  These unregistered tags will not be
       protected from name clashes.

   I. Does the proposal require/expect any changes in DNS
      servers/resolvers that prevent the new type from being processed
      as an unknown RRTYPE (see [RFC3597])?

      No, the unknown RRTYPE from RFC3597 can handle KREALM.

   J. Comments:

      The I-D for this RRtype has been proposed on the DNSEXT list and
      suggestions for improvement were supplied by Mark Andrews on Sep
4, 2015.
      These suggestions have all been incorporated into version 03 and
shared
      back with Mark and the DNSEXT list on Sep 6, 2015.  There have been no
      further comments on the proposal.

      New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Sep 2015 10:03:15 +0100

> nowadays the broad acceptance of DNSSEC permits this facility.

Why not use the HINFO RDATA format to store the tag/value pairs? No need
for embedding the sequence in the RDATA since RRsets already provide that.
No need to embed a version number since RRtypes provide that.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 11 Sep 2015 11:58:36 +0200

Hi Tony / list,

> No need to embed a version number since RRtypes provide that.

Interesting suggestion, I wasn't aware of this possibility.  Indeed, a binary string with prefixed length should work, I see that escaping has been arranged in RFC 1035 and 255 data bytes isn't a strange upper limit for a string.

I can't seem to find a tag/value definition format for HINFO though; can you give me a reference?  I wanted to avoid requesting a parser that specific, but if it's already there then it's certainly a good idea.

Note that ASN.1 is a home game to Kerberos, so from that perspective the wire format makes a lot of sense, I think.  You are not proposing to change the wire format, right?

Thanks
 -Rick

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Sep 2015 11:18:23 +0100

Rick van Rein <[email-masked]> wrote:
>
> I can't seem to find a tag/value definition format for HINFO though; can
> you give me a reference?  I wanted to avoid requesting a parser that
> specific, but if it's already there then it's certainly a good idea.

HINFO is just a pair of strings. (Similar to a TXT record, except a TXT
record can have any number of strings.)

https://tools.ietf.org/html/rfc1035#section-3.3.2

> Note that ASN.1 is a home game to Kerberos, so from that perspective the
> wire format makes a lot of sense, I think.  You are not proposing to
> change the wire format, right?

Yes, I think the wire format and presentation format should be native DNS
not ASN.1.

Tony.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 11 Sep 2015 13:04:53 +0200

Hi Tony,

> Yes, I think the wire format and presentation format should be native DNS

Ah.  That would call for more complex parsing.  I hadn't expected that to be preferred by the DNS community, over simplicity.  Is the reason readability of zone files?

HINFO uses precisely 2 strings, with KREALM it'd be variable, but could be done with something like

@ IN KREALM ( "realm=EXAMPLE.COM" "realm=EXAMPLE.ORG"
      admin=carl "admin=mary"
      service=HTTP "service=imap" )

The parser then MAY check the presence of an = sign in the string but otherwise keep tag and value together.

Each of these strings would then independently translate to a separate <character-string>, namely

12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 43 4f 4d
12 72 65 61 6c 6d 3d 45 58 41 4d 50 4c 45 2e 4f 52 47
0b 61 64 6d 69 6e 3d 63 61 72 6c
0b 61 64 6d 69 6e 3d 6d 61 72 79
0d 73 65 72 76 69 63 65 3d 48 54 54 50
0d 73 65 72 76 69 63 65 3d 69 6d 61 70

But that's a variable number of strings in the textual format *and* in the RDATA format.  The RDATA is preceded by RDLENGTH, so it would be possible, but I am hesitant about such new approaches to DNS.

Alternatively, we could incorporate separator characters such as comma's but that would constrain the possible string values (and call for even more escaping and another level, which isn't my favourite place to go).

I expect an uproar from both alternatives to be honest.  Or not?

-Rick

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Sep 2015 12:09:16 +0100

>       service=HTTP "service=imap" )

I was thinking

@	KREALM	"realm" "EXAMPLE.COM"
	KREALM	"realm"	"EXAMPLE.ORG"
	KREALM	"admin" "carl"
	KREALM	"admin" "mary"
	KREALM	"service" "HTTP"
	KREALM	"service" "imap"

Tony.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 11 Sep 2015 13:14:34 +0200

Hi Tony,

Thanks for thinking along!

> KREALM "realm" "EXAMPLE.ORG"

That would make it impossible to express everything that is desired. 
The level of alternation that you are using here has been reserved for
independent statements; the combined tag=value statements form a
cross-product; for example all the realms mentioned combine with all the
admins mentioned in the same RDATA portion.  If another realm has
another admin set it will be specified in a separate KREALM.

This is why I end up with a variable list of tag=value assignments under
one KREALM, and as explained that strikes me as an oddball solution in
DNS.  Do you agree?

Note that more base64 data is incorporated into DNS already, for
instance certificates (where, I admit, there is no choice due to the
tightness of the signatures).

-Rick

---

From: "Niall O'Reilly" <[email-masked]>
Date: Fri, 11 Sep 2015 14:40:11 +0100

On Fri, 11 Sep 2015 12:14:34 +0100,
Rick van Rein wrote:

  Hi, Rick.

> another admin set it will be specified in a separate KREALM.

  Don't you end up with a potentially large but sparse matrix of
  valid tag/value pairs in this model, Rick?

  Would a two-stage representation of the data you need work?
  I'm thinking of normalization and foreign keys.

  Here's an example below.

    ; advertise realms to which $ORIGIN belongs
    ; so that clients can perform discovery
    ; this RRset is the REALM-SET
    @ KREALM "realm" "EXAMPLE.COM"
    @ KREALM "realm" "EXAMPLE.ORG"
    ;
    ; for each realm at $ORIGIN, advertise its attributes
    ;
    ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.COM" at $ORIGIN
    EXAMPLE.COM._realm	   KREALM "admin" "carl"
    EXAMPLE.COM._realm	   KREALM "service" "HTTP"
    ;
    ; this RRset is the ATTRIBUTE-SET for realm "EXAMPLE.ORG" at $ORIGIN
    EXAMPLE.ORG._realm	   KREALM "admin" "mary"
    EXAMPLE.ORG._realm	   KREALM "service" "imap"
  
  If the realm isn't really "at" $ORIGIN, a CNAME reference might be
  appropriate.

  If this approach risks string overflow in the owner names, an
  alternative might be to use

    @ KREALM <realm-handle> <realm-name>

  for the REALM-SET, and use the same handle in composing the owner
  name of the ATTRIBUTE-SET, so:

    @ KREALM "r1" "EXAMPLE.COM"
    @ KREALM "r2" "EXAMPLE.ORG"
    r1._realm	KREALM "admin" "carl"
    ; ...
    r2._realm	KREALM "admin" "mary"

  As I write, it occurs to me that it may be more "natural" to assign
  the RDATE fields in the REALM-SET in the reverse order.  That's a
  detail which just needs to be unambiguously specified. 8-)

  This-all seems to keep the option of re-using HINFO as Tony suggested.

  ATB
  Niall

---

From: Rick van Rein <[email-masked]>
Date: Sun, 13 Sep 2015 14:55:45 +0200

Hello Niall / Tony / list,

Good post, thanks!

> valid tag/value pairs in this model, Rick?
No, it's not supposed to be sparse.  If things belong together you put
them in the same KREALM record.  If they don't belong together you put
them in separate ones.  The idea is to capture what belongs together by
putting them in the same KREALM record, for brevity of DNS data.

For instance, "service" declarations would be part of a hostname,
together with the "realm" declarations supported; chances are that
www.example.com has realm "EXAMPLE.COM" and "EXAMPLE.ORG" and service
"HTTP" defined, and perhaps also "host" (for remote login) and "cifs". 
This gives rise to all combinations

HTTP/[email-masked]
HTTP/[email-masked]
host/[email-masked]
host/[email-masked]
cifs/[email-masked]
cifs/[email-masked]

Since this is located at the server name (www) rather than the
DNS-mapped realm name (example.com and example.org) this is not as
sparse as you are thinking, if I guess correctly.
 
The reason for keeping those within one KREALM RDATA structure is that
it enables me to specify one KREALM that definces service=HTTP for both
realms, and the other two could only be made available to one of the
realms.  Note that there is no explicit name for that distinction, but
we could wonder if the realm name would be the prime cause of wanting to
make such distinctions, and that is what you are addressing below.

> I'm thinking of normalization and foreign keys.
Very interesting idea.  In fact I was already doing that somewhat, with
a KREALM "reference  record" at the service name (www) that points to
the "home record" where a more elaborate KREALM "home record" is
located.  The "admin" tag would be typically something to find near the
"home record", which is indeed what I specified.  Still, you are making
it more explicit, which is indeed useful.

You are triggering a lot of thoughts with this, which is good, but it'll
need some time for me to think them over.  I started responding in
detail (left below) but it's unfinished.  It'll will take a few walks in
nature and probably lead to a modified proposal, possibly different on
details.  My start should be to clearly state the use cases for the
KREALM record, and finding the best ways of embedding that into DNS.

Thanks a lot so far!
 -Rick

> @ KREALM "realm" "EXAMPLE.ORG"

Here, $ORIGIN as you call it would be the hostname for the service, so
"www.example.com" for a service like HTTP/www.example.com

> EXAMPLE.ORG._realm KREALM "service" "imap"
And this too would fall under that hostname "www.example.com" and add
details.

There are two things that you've triggered.

The things I described as "home tags" are properties of the realm; the
"admin" tag is the running example.  That would not be defined for
individual services, but under the DNS-mapped realm name (which is just
reading a DNS-formatted realm name with ignored case sensitivity).  So I
would suggest to write those simply as

example.com. KREALM "admin" carl"
example.org. KREALM "admin" "mary"

Now, the service tags could be stored underneath the _realm subname. 
Interestingly, this enables wildcard notation *._realm as well, for example

example.org._realm KREALM "service" "imap"
example.com._realm KREALM "service" "host"
*._realm KREALM "service" "HTTP"

I do like this.  And although the mapping to DNS names as done here
looses the case of the realm, it is no problem, because RFC 4120
prescribes in 7.2.3.1 that "it is necessary that only one of the
possible combinations of upper- and lowercase characters be used in
realm names." -- so the case-sensitive realm name mapped to a
case-insensitive DNS-name as you do it here is supported by the Kerberos
specification.

Note my assumption -- you meant to lookup realm names under _realm
rather than the hostname of a server.

The cost of this is one more DNS query, but targeted at the precise
thing we're looking for, so no search pattern.

Defining a "service" tag in this manner makes it impossible to have a
catchall "realm" tag for an entire domain and apply it to everything. 
But that was also the case with the initial proposal I made.  Drop
"service" tags and it does become possible.  We could debate whether it
is a good idea to always specify the "service" tag and not make the
upward search that I've been looking to settle securely.  I suppose
maximum flexibility is desirable here; especially because the Kerberos
client is built into a protocol-specific client, so it'll know if the
service is available.  That in fact enables another approach, which is
to use service names as the index instead of realm names.

; Alternative approach
HTTP._ksvc KREALM "realm" "EXAMPLE.COM"
HTTP._ksvc KREALM "realm" "EXAMPLE.ORG"
imap._ksvc KREALM "realm" "EXAMPLE.ORG"

The client could now lookup the service that it knows it should use,
under the server's name.  So http://www.example.com would query for
KREALM at HTTP._realm.www.example.com -- again a pattern that won't work
well with wildcards that capture an entire domain, and again that's
related to defining a service in the first place; a wildcard KREALM
would refer everything but this record might be overridden for services,
which feels right.

Notes: I'm not sure if case distinction is getting a problem here.  I'm
assuming the service name doesn't need an underscore prefix, but I don't
know the habits here, SRV does it of course.

> If the realm isn't really "at" $ORIGIN, a CNAME reference might be
Hmm, that sounds like a nest of hornets to me, but it might work.  I'm
not sure it is the best way though; references should contain their
KREALM explicitly and point at the realm name, and KREALM records
defining a home location for kerberos are always going to be local to
the DNS-name that they sort-of claim to hold.

> Rick van Rein <mailto:[email-masked]>
> 11 September 2015 13:14
> Hi Tony,
>
> Tony Finch <mailto:[email-masked]>
> 11 September 2015 13:09
>
> I was thinking
>
> Rick van Rein <mailto:[email-masked]>
> 11 September 2015 13:04
> Hi Tony,
>
>
> Ah. That would call for more complex parsing. I hadn't expected that
> to be preferred by the DNS community, over simplicity. Is the reason
> readability of zone files?
>
> But that's a variable number of strings in the textual format *and* in
> the RDATA format. The RDATA is preceded by RDLENGTH, so it would be
> possible, but I am hesitant about such new approaches to DNS.
>
> Alternatively, we could incorporate separator characters such as
> comma's but that would constrain the possible string values (and call
> for even more escaping and another level, which isn't my favourite
> place to go).
>
> Tony Finch <mailto:[email-masked]>
> 11 September 2015 12:18

---

From: "Niall O'Reilly" <[email-masked]>
Date: Sun, 13 Sep 2015 14:55:11 +0100

On Sun, 13 Sep 2015 13:55:45 +0100,
Rick van Rein wrote:
 [...]
> "www.example.com" for a service like HTTP/www.example.com

  I'm just borrowing a notation from the zone-file '$ORIGIN'
  directive, which (some?) zone parsers use to adjust the current
  value to be substituted for '@'.
  
 [...]
> And this too would fall under that hostname "www.example.com" and add

  Or perhaps just under "example.com", depending on the use case.

 [...]
> rather than the hostname of a server.
 
  Like the service tags in the owner name of the SRV record.
> thing we're looking for, so no search pattern.

  And (IIUC) no scanning of the RDATA to discard the parts of the blob
  that are irrelevant to the instant context.

 [...]
> the DNS-name that they sort-of claim to hold.

  I wasn't sure that such administrative proximity (propinquity?)
  was to be counted on.

  Heel veel succes verder!

  Niall

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 13 Sep 2015 07:17:14 -0700

>    service=HTTP "service=imap" )

Can you explain what you try to express with the statement above? Specifically when two attribute/value pairs are not quoted, but others are.

And be VERY specific and explain what data whoever has that looks up this record. What data do the party have and what data do the party want.

What we have somewhat bad experience with is to have selections made on the RDATA side of resource records (see NAPTR) and instead (as laid out in RFC5507 and RFC6950).

It sounds to me that the one looking for the record know it has domain name and service and looks for realm and admin? Where the two last ones can be multiple. Or is the service also unknown and one want to know what services orb can be used? A subset of services available at this domain?

In the draft I see:

   Two mappings are needed for the given scenario.  One is a mapping
   from the FQDN of a service to its realm name; the other is a mapping
   from the realm name to the Kerberos-specific services such as the
   KDC.  The latter mapping is published in SRV records [RFC4120] and
   such traffic is protected by the Kerberos protocol itself.  The first
   mapping however, has hitherto not been standardised and is ill-
   advised over unsecured DNS because the published information is then
   neither validated by DNS nor does it lead to a protocol that could
   provide end-to-end validation for it.

I though service+fqdn -> realm was using SRV, but the text here say that that is what you try to fix with this new spec. Or is my english failing me?

   Patrik

---

From: Rick van Rein <[email-masked]>
Date: Mon, 14 Sep 2015 09:34:58 +0200

Hi all,

Clearly, I should take care of readable / writeable KREALM records,
rather than stuffing things in base64.  Very well...

1.
I propose to introduce a "groupname" in each KREALM, used to group
various records together like I wanted to do with KREALM records before.
Where I wrote
    KREALM "realm=A,realm=B,realm=C,service=S,service=T"
    KREALM "realm=D,service=S"
I was avoiding spelling out a cartesian product; the above was
describing the realm-service combinations
    A-S, B-S, C-S, A-T, B-T, C-T, D-S
An explicit group (arbitrary byte string that matches[*] to keep data
together like the RDATA above did) can be used as a first argument like in
    KREALM 1 realm A
    KREALM 1 realm B
    KREALM 1 realm C
    KREALM 1 service S
    KREALM 1 service T
    KREALM 2 realm D
    KREALM 2 service S
This enables the same compact notation to describe cartesian products,
it lets us define alternate groups of those to handle exceptions and as
a way to specify one-on-one definitions, and it fits into a fixed RDATA
form that can be read and written by DNS admins without base64 tools. 
It also exploits existing DNS structures to manage data lists.

[*] Don't know what "match" means yet.  We might go for something kinky
with wildcards, but that would complicate the data, complicate using it,
and interpret the byte sequence in a particular manner, so my current
gut feeling is to avoid being fancy and just use strcmp()

2.
There are three or four use cases that I see as valuable at this time:
2a. Kerberos client (or his KDC) knows service name + hostname, and
wants to find a realm name
2b. Kerberos node wants to find the case-sensitive realm name for a DNS
name, in a secure manner
2c. Kerberos node wants to find manual contact information for a realm
administrator (possibly "admin" pointers to a defining DNS node with RP,
CERT, ...)
2d / optional.  Kerberos client wants to perform service discovery under
a realm and/or at a DNS name
Based on these, I should be able to formulate the keys and search
patterns for the data.  It will probably also help me further
materialise the home record distinctive feature.

It will take me some time to collect my thoughts on this.  Also, I
intend to discuss it at the Kitten WG.

Thanks!
 -Rick