Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

Joao Damas <joao@apnic.net> Wed, 23 March 2016 18:25 UTC

Return-Path: <joao@apnic.net>
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 9990912D815 for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2016 11:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.8
X-Spam-Level:
X-Spam-Status: No, score=-6.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=apnic.net
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 2N4jfV_G84y9 for <dnsop@ietfa.amsl.com>; Wed, 23 Mar 2016 11:25:19 -0700 (PDT)
Received: from ao-mailgw.apnic.net (ao-mailgw.apnic.net [IPv6:2001:dd8:8:701::25]) (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 8F23112D5BF for <dnsop@ietf.org>; Wed, 23 Mar 2016 11:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=R2D2; h=received:received:content-type:mime-version:subject:from:in-reply-to:date:cc: x-mao-original-outgoing-id:message-id:references:to:x-mailer:return-path; bh=dNg6SAqatFkye0ppKgbQq6tolJySXxK9Y7pyv+h8m6s=; b=K6qiZZqFe/I6TomADpBJFdnR060kyfDzQ0oV7M+9hWi5eV1CWiD/tqzJx1Zds2dw+bjwiW9tbQDel avWIxPwu8P/qXr2LgqmN2tj/cJ8WWo4wP57uIX84d3G3v315Pzf3xOoUMPxHmCUxWWqk5k9557+Y0+ 3dodbKG1WVkVgqmc=
Received: from NXMDA2.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ao-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Thu, 24 Mar 2016 04:25:13 +1000 (AEST)
Received: from [204.62.249.33] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 24 Mar 2016 04:24:53 +1000
Content-Type: multipart/signed; boundary="Apple-Mail=_F3782DBF-C8CD-4979-B43D-0893797713DE"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Joao Damas <joao@apnic.net>
In-Reply-To: <CAN6NTqzhkm5cbt4p0zz4p3DX0x_sfxFYKmi7gJHCe_cgUqsNEg@mail.gmail.com>
Date: Wed, 23 Mar 2016 19:24:24 +0100
X-Mao-Original-Outgoing-Id: 480450263.609906-6b708416e8bd0ec74acc3062884c63f8
Message-ID: <61CDE589-46AB-47DF-A132-13DECB5E173D@apnic.net>
References: <CAC=TB13r_7TPEcUeZqH6sxqKXHRn7TgFwLwdqjBxa57aqS1MZg@mail.gmail.com> <alpine.LSU.2.00.1603221140220.11434@hermes-2.csi.cam.ac.uk> <CAHPuVdVMMYny9d68fGeLPKUWZvEjD+Kk-in6eFrO=sND7bRtQw@mail.gmail.com> <CAC=TB11OrH1Myro+CCEMJWy67nYhDCrGWVhe+jM568o2CL7vEA@mail.gmail.com> <20160322220345.29993c71@pallas.home.time-travellers.org> <20160322221132.8EF8644D6694@rock.dv.isc.org> <CAN6NTqzhkm5cbt4p0zz4p3DX0x_sfxFYKmi7gJHCe_cgUqsNEg@mail.gmail.com>
To: Ólafur Guðmundsson <olafur@cloudflare.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/4VsJEDbfWFechaCvQpWC1YiRPrE>
Cc: Shane Kerr <shane@time-travellers.org>, Tony Finch <dot@dotat.at>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Marek Vavruša <mvavrusa@cloudflare.com>
Subject: Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free
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: Wed, 23 Mar 2016 18:25:21 -0000

In one of the experiments we are conducting we stuff the response with other QTYPE data and this seems to not interfere with resolver behaviour (unless we trigger it). So #3 doesn’t seem to be a common case (we could look in the fringes for this behaviour).

Towards the resolver’s clients, all extraneous data gets cleaned out of the response, which is quite sane behaviour in the current DNS. Have not tested what the resolver does with the data (keep it in cache, something in between #1 and #2, or discard it altogether, as in #2).

Joao


> On 23 Mar 2016, at 19:17, Ólafur Guðmundsson <olafur@cloudflare.com> wrote:
> 
> 
> On Tue, Mar 22, 2016 at 6:11 PM, Mark Andrews <marka@isc.org <mailto:marka@isc.org>> wrote:
> 
> In message <20160322220345.29993c71@pallas.home.time-travellers.org <mailto:20160322220345.29993c71@pallas.home.time-travellers.org>>, Shane Kerr writes:
> > Maybe we just need a new RTYPE. It would be awesome if CloudFlare
> > killed ANY and then gave us ANYA ("any address"). ;)
> 
> You would then need to do ANYA, A and AAAA queries or you have to
> have signaling to indicate if the server supports ANYA with fallback
> to A and AAAA on no support.  Now for named you go from NOTIMP ->
> NOERROR/NXDOMAIN introducing a meta type but for other servers you
> start at NOERROR/NXDOMAIN so explicit signaling of support for a
> meta type is needed.
> 
>  
> There are two ways to approach the address distribution problem, 
> a) from the client side 
> b) from the server side 
> our proposal is strictly in camp b) i.e. just servers put this out. 
> 
> The OPEN question is what will resolvers do 
> #1 Accept but RRsets
> #2 Discard non QTYPE covered set 
> #3 discard the answer 
> 
> If it is #3 then this is a horrible idea, 
> if is #2 then there is no loss and resolvers will improve over time. 
> if it is #1 then it is a win without any resolver changes. 
> 
> Tony, 
> Same questions apply if AAAA set is put in the additional section. 
> 
> Andrew, 
> We need data to determine if this is feasible. 
> 
> 
> Olafur
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop