IETF Logo Mail Archive

Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01

David Conrad <drc@virtualized.org> Thu, 21 August 2014 01:52 UTC

Return-Path: <drc@virtualized.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDF61A6F85 for <dnsop@ietfa.amsl.com>; Wed, 20 Aug 2014 18:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 S0GHdXuGWvmu for <dnsop@ietfa.amsl.com>; Wed, 20 Aug 2014 18:52:08 -0700 (PDT)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67F821A6F84 for <dnsop@ietf.org>; Wed, 20 Aug 2014 18:52:08 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id kx10so13085172pab.34 for <dnsop@ietf.org>; Wed, 20 Aug 2014 18:52:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=nUyvv7Wdt1GpGvx5ePJTLWaO6CYFHhe9+RhCv/+Lj68=; b=VPqfmzdmzEnxrsW1vEo500AU7NC3JewB6vQAo1362RoM1lOTRB+2avORPsZTpzlEFi HAAFJEQYIfEdTveitY17FNldvX9JcOF7bh6jdcZ8VHdEnQ9SlWwarsWAeycm4geEtR2D ZrMmltTwQ8eG2K4fv+MUB4z0HDYLxpjiArWxwxqAYCQcrl5C3uu9E0x31IdXyqFs8zHh ChysFUuqfpUOKGeQanoQSnHO4NmKwwxolAJPZoWZfUU+0hG7RJjRAZnbnDzv/K3qbs+Y CD3e2stlI1gODZM9wk45ysVks4SuB9IjXrZX78P0/0pZwkFsi/Y9sexUxKZwAHTs9iRn 5T4w==
X-Gm-Message-State: ALoCoQmnY0S0pXOeXBnYMtYzrVtHbGxxoGWe51Au+Dn+t9B4ViJZSfoRz3XetKFJ7pEW6uPsGG0F
X-Received: by 10.70.34.39 with SMTP id w7mr64236005pdi.19.1408585928039; Wed, 20 Aug 2014 18:52:08 -0700 (PDT)
Received: from [10.0.1.11] ([73.162.11.38]) by mx.google.com with ESMTPSA id ks7sm6152635pbc.26.2014.08.20.18.52.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 18:52:07 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_5877BFB7-2C47-4DB2-9AF3-040EA4770A89"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: David Conrad <drc@virtualized.org>
In-Reply-To: <20140821012100.GC2837@mx1.yitter.info>
Date: Wed, 20 Aug 2014 18:51:58 -0700
Message-Id: <54885A5D-2AFA-4D37-9B83-2229082D7BA4@virtualized.org>
References: <20140814001610.3124D1CC688D@rock.dv.isc.org> <86AC48C0-4DFF-4286-A9B1-2A6BE3D14BDC@hopcount.ca> <20140814160453.1C7931CCE03D@rock.dv.isc.org> <7EA38D42-3915-403E-AFE3-C0A8E4A391BF@hopcount.ca> <Prayer.1.3.5.1408201750020.12368@hermes-1.csi.cam.ac.uk> <19AE3CB3-B108-42CB-BAE2-A2F1FBB55EF4@hopcount.ca> <20140820214845.70AEA1D1A20E@rock.dv.isc.org> <E4AD7D21-995C-46B1-813E-70CA0919F6CE@hopcount.ca> <20140820235118.E952B1D1B042@rock.dv.isc.org> <20140821005246.E3C7D1D1B8C8@rock.dv.isc.org> <20140821012100.GC2837@mx1.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/O6MFnTn3oT8APSOK5jkqPsYP-hY
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-ietf-dnsop-rfc6598-rfc6303-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 01:52:10 -0000

Hi,

On Aug 20, 2014, at 6:21 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

> On Thu, Aug 21, 2014 at 10:52:46AM +1000, Mark Andrews wrote:
>> It was also a required step as you can't reliably
>> validate in the client unless the recursive server has filtered out
>> the spoofed answers.
> 
> If I understand you correctly, this devolves to the claim that the
> validating client has to do its own recursion, lest it trut something
> without basis.  Is that what you're suggesting?  I'm not opposed, but
> let us be clear.

I’m getting confused.

What’s the difference between the “validating client” and a full validating resolver?  Just the lack of cache?

Tanks,
-drc

v2.46.0 | Report a Bug | By Email | System Status