[dnsext] 2929bis DNS assumptions [was RRTYPE request: template for ZS record]

Olaf Kolkman <olaf@NLnetLabs.nl> Sat, 22 November 2008 13:30 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18AAA3A6868; Sat, 22 Nov 2008 05:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.337
X-Spam-Level:
X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhQHQLtCC7O2; Sat, 22 Nov 2008 05:30:13 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 2DA243A6816; Sat, 22 Nov 2008 05:30:13 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1L3sVM-000Htd-Tl for namedroppers-data@psg.com; Sat, 22 Nov 2008 13:26:32 +0000
Received: from [2001:7b8:206:1::1] (helo=open.nlnetlabs.nl) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <olaf@nlnetlabs.nl>) id 1L3sVH-000HtL-4V for namedroppers@ops.ietf.org; Sat, 22 Nov 2008 13:26:29 +0000
Received: from [130.129.77.247] ([130.129.77.247]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id mAMDQK9J087957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Nov 2008 14:26:22 +0100 (CET) (envelope-from olaf@nlnetlabs.nl)
Cc: Andrew Sullivan <ajs@shinkuro.com>, namedroppers@ops.ietf.org
Message-Id: <09A5C945-E769-4763-92BC-2A9032FE5502@nlnetlabs.nl>
From: Olaf Kolkman <olaf@NLnetLabs.nl>
To: Jim Reid <jim@rfc1035.com>
In-Reply-To: <BB2EC28B-178B-4DA8-9C14-31ED75BE2C07@rfc1035.com>
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Apple-Mail-24--54930702"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: [dnsext] 2929bis DNS assumptions [was RRTYPE request: template for ZS record]
Date: Sat, 22 Nov 2008 07:26:12 -0600
References: <20081121190348.GB20868@shinkuro.com> <D7045FFF-1746-4ADD-AF56-0B876E031D51@NLnetLabs.nl> <BB2EC28B-178B-4DA8-9C14-31ED75BE2C07@rfc1035.com>
X-Pgp-Agent: GPGMail d54 (v54, Leopard)
X-Mailer: Apple Mail (2.929.2)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (open.nlnetlabs.nl [213.154.224.1]); Sat, 22 Nov 2008 14:26:23 +0100 (CET)
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

On Nov 21, 2008, at 11:02 PM, Jim Reid wrote:

>>
>> That suggests that the applications that use this RR need to be  
>> aware of the administrative boundaries in the domain namespace.
>
> They don't. They lookup a name (singular) and if they get a ZS  
> record back, that's it. If there's nothing there, they give up. No  
> searching or tree walking is involved whatsoever.

The name of the record and the specification made me wonder: question  
needed to be asked. Your answer is clear. It is probably good to add  
this clarification to the request before it disappears in the archives.

>
>
>> We do not have a good mechanism to find those zone boundaries and  
>> that indicates that there is more to this than simply query- 
>> response; there will be a bit of searching.
>
> There is nothing more than a simple query-response going on. It's  
> wrong to suggest or imply otherwise.

Although my mail did not contain question marks it was intended as a  
question ('if the above assumption is correct').

More to draft-ietf-dnsext-2929bis than to your request. I think that  
if a specification assumes knowledge of administrative boundaries in  
the domain namespace than that is an argument to deny the code point.  
I would think that such would be an incorrect assumption about DNS  
protocol behavior. Which could be, absent further specification, a  
reason to deny the code point. Is that a reasonable assumption?

--Olaf