Re: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt
Rick van Rein <rick@openfortress.nl> Fri, 04 September 2015 06:38 UTC
Return-Path: <rick@openfortress.nl>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234081B3815 for <dnsext@ietfa.amsl.com>; Thu, 3 Sep 2015 23:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0baKfosrrtU for <dnsext@ietfa.amsl.com>; Thu, 3 Sep 2015 23:38:31 -0700 (PDT)
Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30911B3802 for <dnsext@ietf.org>; Thu, 3 Sep 2015 23:38:29 -0700 (PDT)
Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id CueQ1r00T10HQrX01ueSaS; Fri, 04 Sep 2015 08:38:27 +0200
Message-ID: <55E93C5F.5080704@openfortress.nl>
Date: Fri, 04 Sep 2015 08:38:23 +0200
From: Rick van Rein <rick@openfortress.nl>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Mark Andrews <marka@isc.org>
References: <55E868E8.6050504@openfortress.nl> <20150903221410.8405236BD3C5@rock.dv.isc.org>
In-Reply-To: <20150903221410.8405236BD3C5@rock.dv.isc.org>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsext/V74OTC-NCbN5kJbh0goEgwNRXOs>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] New RRtype "KREALM" in draft-vanrein-dnstxt-krb1-02.txt
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2015 06:38:34 -0000
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? > 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. 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. > 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. > 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
- [dnsext] New RRtype "KREALM" in draft-vanrein-dns… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Mark Andrews
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Tony Finch
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Tony Finch
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Tony Finch
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Niall O'Reilly
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Niall O'Reilly
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Patrik Fältström
- Re: [dnsext] New RRtype "KREALM" in draft-vanrein… Rick van Rein