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

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--===============0897380167839267462==
Content-Type: multipart/signed;
 boundary="=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_=";
 micalg=pgp-sha1; protocol="application/pgp-signature"

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On 11 Sep 2015, at 4:04, Rick van Rein wrote:

> HINFO uses precisely 2 strings, with KREALM it'd be variable, but could=
 be done with something like
>
> @ IN KREALM ( "realm=3DEXAMPLE.COM" "realm=3DEXAMPLE.ORG"
>    admin=3Dcarl "admin=3Dmary"
>    service=3DHTTP "service=3Dimap" )

Can you explain what you try to express with the statement above? Specifi=
cally 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 t=
he 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 na=
me 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 se=
rvices 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

--=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlX1hWoACgkQrMabGguI181MCQCdF4uM0+KL7uSeEExqCFnygpAn
bCYAn0tdV/H84NHA4aNVXpoSyqNjbK8p
=Jk06
-----END PGP SIGNATURE-----

--=_MailMate_A79E5803-8954-4F04-8D69-9F745ED72BD3_=--


--===============0897380167839267462==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext

--===============0897380167839267462==--