Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Marek Vavruša <mvavrusa@cloudflare.com> Thu, 18 August 2016 18:29 UTC

Return-Path: <mvavrusa@cloudflare.com>
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 7788012D901 for <dnsop@ietfa.amsl.com>; Thu, 18 Aug 2016 11:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
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 JgyjtY8wyy0B for <dnsop@ietfa.amsl.com>; Thu, 18 Aug 2016 11:29:11 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BCB12D7AE for <dnsop@ietf.org>; Thu, 18 Aug 2016 11:29:11 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id u134so14732579ywg.3 for <dnsop@ietf.org>; Thu, 18 Aug 2016 11:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8tBYRg89HgS9+dUrD0Va7h8yo+tHoAOmr2bsBF6ckAE=; b=OQThRc8ox5LZ+dRzuv/IscNHab/PT/JWPlltrqR/20pYohjMipZJ/1VSvEjpcDxJsz T9mlPKreTccJxQgzHQ+8EXaaJWC259r7UtuEeYow+Yz4xOpydGzwILMPfWgj2JVaW+Uh lf+r3v9ILz7bx+xqVEWM92EGd8GK3z7z1ckJw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8tBYRg89HgS9+dUrD0Va7h8yo+tHoAOmr2bsBF6ckAE=; b=Xcs4TeII1CXSO+/4G3dpJnUPc/1DqXwd/nGn/c+qBkzh446V5dhA/RUHfeE5bWgeha fovDSVDc1rM2wQVuCdp2AHXU/80VXSspsmQM7Tpv4COY1IfAl1u6DZ1YbXBjTsFcb8le /uhUhvvK6dL6tKEE1P5AGZncBFJ1Uaq3sKZyyro776w/55hrLwxnBtrzOaAG37Zoavg3 vDRvjEbgivOkREHBKYtaso28DGaLxMPV+4k+v/DT/hTkYLujCmc/k6bVKRdMBRKrNDeQ qhlUtvGTVyIs2qizKwULKE7OcJTGHPZLSmQVDlSWLqG6FXMo/J43oKSYejx7fGl13Lmf 20gQ==
X-Gm-Message-State: AEkoouug/wyUztqygjg0QGIXK1KoVD7Yx/UuxQI+Cugc8bSgYH9+SFU8Z2+XtD+FAA38hh+6jJAKIxVoJy8FJqrS
X-Received: by 10.129.129.134 with SMTP id r128mr2947714ywf.179.1471544950679; Thu, 18 Aug 2016 11:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.164.199 with HTTP; Thu, 18 Aug 2016 11:29:09 -0700 (PDT)
In-Reply-To: <20160818175713.16299.qmail@ary.lan>
References: <DAE8C592-A5A6-4EDA-A100-67B7DD900C36@vpnc.org> <20160818175713.16299.qmail@ary.lan>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Thu, 18 Aug 2016 11:29:09 -0700
Message-ID: <CAC=TB12PtSpU3_mL0+QdmJwqvfYm4go=fmtK80aRg7On6XgfHg@mail.gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I_D9433CBtWgWO7tLRyjEU1qvmg>
Cc: dnsop <dnsop@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] The Larger Discussion on Differences in Response Drafts
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: Thu, 18 Aug 2016 18:29:13 -0000

Or SRV. These are cases where authoritative/resolver adding
interesting records as additionals works better.
Authoritatives have been doing that with extra SOA/NS in authority for
a while (for positive answers), but now
resolvers can hardly use them if these records are not secure.

Regardless of which draft is going to be adopted, it should be
explicitly stated which records should client accept.
e.g. pushed A+AAAA matching QNAME could be accepted even from insecure
zones, but records matching SRV target shouldn't be.

Marek

On Thu, Aug 18, 2016 at 10:57 AM, John Levine <johnl@taugh.com> wrote:
>>Are there QTYPEs that, when I ask for them, I won't know that I should
>>also ask for the related info?
>
> NAPTR
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop