IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http

Marek Vavruša <mvavrusa@cloudflare.com> Tue, 12 July 2016 04:30 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 29E6F12B046 for <dnsop@ietfa.amsl.com>; Mon, 11 Jul 2016 21:30:28 -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 Xf0x9nI4789t for <dnsop@ietfa.amsl.com>; Mon, 11 Jul 2016 21:30:26 -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 7DD4612B029 for <dnsop@ietf.org>; Mon, 11 Jul 2016 21:30:26 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id w127so3829547ywf.3 for <dnsop@ietf.org>; Mon, 11 Jul 2016 21:30:26 -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=GF1CCkSsy/pbmVRFDTW52mBycrum+BT+IXDyheuAMPY=; b=O0lkaxStukzmeM5wddRCCKbuK4wukaARpbR8K+dwPKS4XqCo+t7mhBlvKxpQDaBknP kCUKtpTjEuEAKJW4cm4cxl+JI8zH/+khHMzzuw1tLZeI3mLXxnyLzp6+j5jSdxOXe8QU QHoCJjux8zQCGD/dvdIYNJuiiIXvmH0aJKPhM=
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=GF1CCkSsy/pbmVRFDTW52mBycrum+BT+IXDyheuAMPY=; b=HIbHzl91ArYm5Sh5xoK40SLARkuAGVHGP+I1a1VK83FHcNDoCZHpAYpRXa9Z79ohzZ lYrINpVrnDatqpWhZHMelNnLLDTm2+ghsLfAUyd/jTCJ+2qryuAsykwsuJHB66IZuYz6 ZoVE7soP98Y2JV2KDWCxsWiSsFlutkibml//+UATA9P65ltTJC/rka+a/PGIbQtUDZ4u aWUsuRhU8p1MH5wM11XGEPNhDCOYbhCeyU2F8wkI1x/W4bvGQXUM92lyQ2SIwzoWQbLG e6dKbB0o8Gkui1C4sDOly9YEmHUyzwsfOSfbZUPayO5nmyI31tRSWNP3jBLOPyigfV58 6L6w==
X-Gm-Message-State: ALyK8tLIU2EcfHF2jrYtkBEXRc4h4ZU6IbX9LElUoLeJKmeTAk72902dC2gjpj4xhFwOJtaXmKTY5M7yCF1yY7yB
X-Received: by 10.37.207.208 with SMTP id f199mr118548ybg.4.1468297825666; Mon, 11 Jul 2016 21:30:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.32.137 with HTTP; Mon, 11 Jul 2016 21:30:25 -0700 (PDT)
In-Reply-To: <alpine.OSX.2.11.1607112336330.48266@ary.lan>
References: <emb8d27236-31f5-4f14-ab78-4f26f9db49e2@bodybag> <alpine.OSX.2.11.1607112336330.48266@ary.lan>
From: Marek Vavruša <mvavrusa@cloudflare.com>
Date: Mon, 11 Jul 2016 23:30:25 -0500
Message-ID: <CAC=TB13Kk0mamdt-KHMd67SxMuzPVsPWdodGp7DAp82Z_tZuGw@mail.gmail.com>
To: John R Levine <johnl@taugh.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/aXIK9MV_vAOtWZMeEsvoQssp8zg>
Cc: Adrien de Croy <adrien@qbik.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption: draft-song-dns-wireformat-http
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: Tue, 12 Jul 2016 04:30:28 -0000

On Mon, Jul 11, 2016 at 10:39 PM, John R Levine <johnl@taugh.com> wrote:
>> for a web to DNS proxy to decide to send a reply back, it would need to
>> consider it complete?
>>
>> Or are you proposing that the http server would start streaming back the
>> payload as it received the (possibly out of order) replies?
>
>
> I was thinking that the proxy would get all the queries from the DNS
> request, deal with them however it wants, maybe stuff them to a nearby DNS
> cache with TCP if it pipelines properly, or split them up into separate
> requests if it doesn't, then collect the responses and send them back when
> it has them, which I guess would constitute streaming.  RFC 7766 says that
> out-of-order is fine.

Without HTTP/2 each request, clients would need to start a separate
connection to get parallel processing, which means TCP handshake and
potentially a TLS and more bookkeeping code. So client makes requests
to proxy over HTTP/2 to mitigate the costs (here 7766 doesn't apply).
Then proxy translates incoming HTTP/2 multiplexed requests into either
DNS/TCP queries to origins (here 7766 helps)  or plain old DNS
(additional costs and bookkeeping). Server sends back DNS responses to
proxy, which in turn translates them to DNS/HTTP answers. So both
DNS/TCP out-of-order processing and DNS/HTTP out-of-order processing
is desirable here.

> I suppose with http/2 we get two-way streaming more or less for free.
>
> R's,
> John

Yep, the proxy can also push DNS answers to client ahead of time,
which is interesting and something DNS servers can't do right now. On
another note - this proposal kind of competes with DNS over HTTP
encoded in JSON. While that one doesn't transport exact byte-by-byte
DNS messages, it's much more consumer-friendly and elegant than
piggybacking binary data. I wonder why that one is not getting more
attention.

Marek

>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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