Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

Mark Andrews <marka@isc.org> Fri, 26 August 2016 12:14 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206DF12D67A for <dnsop@ietfa.amsl.com>; Fri, 26 Aug 2016 05:14:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.449
X-Spam-Level:
X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XbiBHzZSIliE for <dnsop@ietfa.amsl.com>; Fri, 26 Aug 2016 05:14:47 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F335712B00B for <dnsop@ietf.org>; Fri, 26 Aug 2016 05:14:45 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id F17043494F4; Fri, 26 Aug 2016 12:14:43 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E1FA4160076; Fri, 26 Aug 2016 12:14:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CA79116006B; Fri, 26 Aug 2016 12:14:43 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j66HTbzIzAhO; Fri, 26 Aug 2016 12:14:43 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 85CB216003A; Fri, 26 Aug 2016 12:14:37 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 92B455286C51; Fri, 26 Aug 2016 22:14:33 +1000 (EST)
To: Edward Lewis <edward.lewis@icann.org>
From: Mark Andrews <marka@isc.org>
References: <BC3FCB73-3ECA-4374-8AD5-845A452B6835@icann.org> <20160825043551.GP4670@mournblade.imrryr.org> <20160825072545.36iklvmpcfcpqawg@nic.fr> <CACfw2hjDNQcZo1To2wv=oAhDF1avDwJvA1myG4NgyYjRF95zSg@mail.gmail.com> <alpine.DEB.2.11.1608251203310.14525@grey.csi.cam.ac.uk> <CACfw2hguojqbictc0RvLFQiY=1BVdQ+qA0Ot_ztdZEndHUy+Hg@mail.gmail.com> <alpine.DEB.2.11.1608251719360.2933@grey.csi.cam.ac.uk> <CAC=TB12DFHmAndeb3fJNYr1sdS6U4GOrAoKZHZUcMfh7WXmrJA@mail.gmail.com> <20160825191928.mze4bbzypq2ml2uv@nic.fr> <20160825215635.B6693523BE94@rock.dv.isc.org> <47E7E680-4554-4978-B3A6-17DE2690A9FC@icann.org>
In-reply-to: Your message of "Fri, 26 Aug 2016 11:19:03 +0000." <47E7E680-4554-4978-B3A6-17DE2690A9FC@icann.org>
Date: Fri, 26 Aug 2016 22:14:33 +1000
Message-Id: <20160826121433.92B455286C51@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/G0CL02oOaHTQARP9hef3Iaik5y8>
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 26 Aug 2016 12:14:48 -0000

In message <47E7E680-4554-4978-B3A6-17DE2690A9FC@icann.org>, Edward Lewis write
s:
> On 8/25/16, 17:56, "DNSOP on behalf of Mark Andrews" <dnsop-bounces@ietf.org 
> on behalf of marka@isc.org> wrote:
> 
>     >    If you don't want to implement a EDNS than don't implement it.  If
>     you don't want to use a EDNS option with some client then just
>     ignore the option.  Similarly for EDNS flags.  The client is expecting
>     that unsupported options and flags will be ignored not used to
>     decide to drop a query.
> 
> If this is your intended message, stick to that in the draft.  I.e., don't go
>  beyond the message by requiring responses to queries, reinforce how to respo
> nd if the server isn't implementing EDNS0.  Don't direct operators to perform
>  maintenance checks, that has little to do with properly implementing the EDN
> S mechanism, stick with making sure implementers know what to code up.  Maybe
>  this is "clarifications on EDNS response behavior" and not "no response issu
> e".

It's not just EDNS.  "dig +ad +noedns" -> no response.

If you would answer any query from a address you need to answer ALL
query types from a address.  Resolvers shouldn't have to play 50
queries to get a answer.

The draft doesn't require EDNS.  It requires that EDNS be fully
implemented if you implement EDNS.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org