IETF Logo Mail Archive

Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers

Paul Hoffman <paul.hoffman@icann.org> Sat, 27 June 2020 15:05 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812633A02C1 for <add@ietfa.amsl.com>; Sat, 27 Jun 2020 08:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 d0HK9Q_SEYoo for <add@ietfa.amsl.com>; Sat, 27 Jun 2020 08:04:58 -0700 (PDT)
Received: from ppa3.lax.icann.org (ppa3.lax.icann.org [192.0.33.78]) (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 F10463A0112 for <add@ietf.org>; Sat, 27 Jun 2020 08:04:57 -0700 (PDT)
Received: from PFE112-CA-1.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) by ppa3.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 05RF4v0f005109 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 15:04:57 GMT
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sat, 27 Jun 2020 08:04:55 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1497.006; Sat, 27 Jun 2020 08:04:55 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Eric Rescorla <ekr@rtfm.com>
CC: ADD Mailing list <add@ietf.org>
Thread-Topic: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers
Thread-Index: AQHWTBsN3/DLN2hcME+JF5GYFgXFVajtBcSA
Date: Sat, 27 Jun 2020 15:04:55 +0000
Message-ID: <8FC68464-A7B8-48C9-BDDC-333207C16FD4@icann.org>
References: <CABcZeBPTkWeB40wpTowKvEJ-gXA3AL2e-BE+C_FC7Js7-D0DZQ@mail.gmail.com> <0478F516-47AE-419E-B95D-F546A2F12ABB@icann.org> <CABcZeBPMrn_H8EQfw3ksLnsMJd21=BTZ3h29g-rMnKO2SUJOFw@mail.gmail.com>
In-Reply-To: <CABcZeBPMrn_H8EQfw3ksLnsMJd21=BTZ3h29g-rMnKO2SUJOFw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_C26EE232-EDB8-4298-BCAC-80AE817AE054"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-27_04:2020-06-26, 2020-06-27 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/m-MbmRzzCUOjq7RpeAJ5isHYWAQ>
Subject: Re: [Add] [Ext] Draft Posting: CNAME Discovery of Local DoH Resolvers
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2020 15:05:01 -0000

On Jun 26, 2020, at 5:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> Point 1 feels overstated. The clients we are talking about here are modern web browsers, which can clearly write whatever they want in their DNS queries.
>> 
> "clearly" is doing a lot of work here. Sure, it's just software so we could do this. However, Firefox uses the system resolver and in particular calls getaddrinfo(). So while yes, we could in theory write our own resolver or plumb to the OS-specific more flexible interfaces (e.g. res_query()) up to the part of the code that needs this information. Hence, as I said, "somewhat more difficult (though not impossible)".

I assumed that Firefox was using an internal mechanism for creating the DNS queries in the draft. How can Firefox send a CNAME query if it "uses the system resolver and in particular calls getaddrinfo()"? I admit weakness here, but I thought that getaddrinfo() doesn't let you specify the RRtype, just "give me an address" where "address" is defintely not "a domain name".

If Firefox has the means of sending a constructed CNAME query and process the response, shouldn't it also (ahem) clearly have the means of sending a constructed TBD1 query and process the response?

--Paul Hoffman

v2.23.0 | Report a Bug | By Email