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

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 protected]>, Rick van Rein writes:
> 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-k
> rb1-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.
> >
> 
> _______________________________________________
> dnsext mailing list
> [email protected]
> 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 protected]

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