IETF Logo Mail Archive

Re: QUIC re-chartering: include DNS-over-QUIC?

"Salz, Rich" <rsalz@akamai.com> Wed, 05 February 2020 01:50 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850E012006E for <quic@ietfa.amsl.com>; Tue, 4 Feb 2020 17:50:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 JmzTri7oGv0z for <quic@ietfa.amsl.com>; Tue, 4 Feb 2020 17:50:01 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A7FB6120058 for <quic@ietf.org>; Tue, 4 Feb 2020 17:50:01 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 0151jjZN006302; Wed, 5 Feb 2020 01:49:56 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=8opgXfq4XPDGMRWiq/Ahy64ZrRImeXDq47mrV4+m5Z8=; b=mmMN05teoAcF3oQkUYN/Kr7GayhndAvYxs+Idx6d9107F8klM4xJJ7iA9uq0CYo97c9N FwOkGBWa3AqPwcsyEUt+oTpxdzEOl8AqAgN2c3rm1spqCaD9RMvQ7NTOjW2OBBRGQH3+ 0BO3WhC1Db+NEJLT+C1e/cq6hY6/Ive20xoKwG/lkYmXpRB6Nqcd+cmFnPJ8ut7s0eoH kLqh5sZektDdxIkroVCQEhxkIV8s+if0k/k6o2mahxS4/SWEE6DpTG0M8wdKfe6c36kB /Wukw5TGjHGkbCniZr7VY4DJCgoHMYnrNMjEwBE/GfxkPD0Q16Id+GXvUxniVCMJ29lZ 2Q==
Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2xyhn5gpy6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 05 Feb 2020 01:49:56 +0000
Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 0151m3Y2019931; Tue, 4 Feb 2020 17:49:55 -0800
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint5.akamai.com with ESMTP id 2xykfu813p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 04 Feb 2020 17:49:55 -0800
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 20:49:54 -0500
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 4 Feb 2020 20:49:54 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, Erik Nygren <erik+ietf@nygren.org>
CC: Lars Eggert <lars@eggert.org>, Mark Nottingham <mnot@mnot.net>, IETF QUIC WG <quic@ietf.org>
Subject: Re: QUIC re-chartering: include DNS-over-QUIC?
Thread-Topic: QUIC re-chartering: include DNS-over-QUIC?
Thread-Index: AQHV258Zea7jxOk5qUmVuA7FYYAzPqgMD8GA///GH4A=
Date: Wed, 05 Feb 2020 01:49:54 +0000
Message-ID: <3E036FFD-7A61-4B5B-8750-4EDF9025B4CE@akamai.com>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <CAKC-DJiuhJurq4ojJwPD0Ag3Eoz_4KwFssuuP5Ts1+EH6C9C2A@mail.gmail.com> <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com>
In-Reply-To: <0FD71EED-6095-4989-A81B-1FEC12044E80@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.22.0.200203
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.114.49]
Content-Type: multipart/alternative; boundary="_000_3E036FFD7A614B5B87504EDF9025B4CEakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-02-04_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2002050012
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-04_09:2020-02-04, 2020-02-04 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 suspectscore=0 mlxlogscore=999 malwarescore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002050011
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2eakp0Lj1ibqxFNgvR9AjIEftAI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Feb 2020 01:50:02 -0000

Erik was suggesting

  *   plus DNS-over-QUIC seems quite attractive as a technology for resolver-to-authoritative communication if/when we go that way.

I’d rather not see HTTP embedded in resolvers except to handle clients.  There’s no reason for the root servers, e.g., to have an HTTP stack.  Smaller attack surface.

DNS seems like a good fit for QUIC; it’s request/response, and it’d be great to not have to care about UDP vs TCP.

v2.23.0 | Report a Bug | By Email