Re: [DNSOP] extension of DoH to authoritative servers

"" <> Thu, 14 February 2019 08:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B74F13103C for <>; Thu, 14 Feb 2019 00:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UtfZHGK2Ag1B for <>; Thu, 14 Feb 2019 00:11:26 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5430A13102D for <>; Thu, 14 Feb 2019 00:11:24 -0800 (PST)
Received: from Foxmail (unknown []) by (Coremail) with SMTP id AQAAf0BJdq2qImVcdQQgAA--.22744S2; Thu, 14 Feb 2019 16:11:22 +0800 (CST)
Date: Thu, 14 Feb 2019 16:11:20 +0800
From: "" <>
To: Paul Wouters <>
Cc: Stephane Bortzmeyer <>, dnsop <>
References: <>, <>, <>, <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 7, 166[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart316714538658_=----"
X-CM-TRANSID: AQAAf0BJdq2qImVcdQQgAA--.22744S2
X-Coremail-Antispam: 1UD129KBjvdXoWrZw4UAr15Wr4kCrW5KryDJrb_yoWDXrc_ur W5C34vvF4rXF1jkw4fKr40vrZ5Zayjyr18Xayjg3Zxt3sIvws3tFnrCF1fZa1rCryDtFZx W3y5Xw43G34jgjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbvxYjsxI4VWkCwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVW8JVWxJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z2 80aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40En4AKxVAv wIkv4cxYr24l5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2js IE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k0 4243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1l7480Y4vEI4kI2Ix0rVAqx4xJMxkIec xEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI 0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVF xhVjvjDU0xZFpf9x07j4PfdUUUUU=
X-CM-SenderInfo: x2xr1vlqj6u0xqlfhubq/
Archived-At: <>
Subject: Re: [DNSOP] extension of DoH to authoritative servers
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Feb 2019 08:11:28 -0000

No. i might did not explain it clearly.  

Regarding connecting requirement, my proposal is no different from existing DNS except the recursive server 
needs to talk to authoritative server via HTTPS(or TLS) using the TLSA record. 
The TLSA record contains child zone's(or the server hosting that child zone, those details can be discussed in the future)
 public key and is published in the parent zone. 
 I mean, for the authoritive servers, the trust chain can be built using TLSA other then DS. then a recursive server can ensure
the data it receives in each step of resolving comes from an authenticated server and is encrypted.
From: Paul Wouters
Date: 2019-02-14 15:34
CC: Stephane Bortzmeyer; dnsop
Subject: Re: Re: [DNSOP] extension of DoH to authoritative servers
On Thu, 14 Feb 2019, wrote:
> This idea is just a sketch model and provides another option for DNS security and privacy. Transiting trust is hard but may be accomplished in the future. T
> he deployment of DNSSEC also takes a long time and is still in progress. 
No. It simply will break applications. For example, the libreswan IKE
daemon using DNSSEC will use the system's forwarder and perform full
DNSSEC validation, without having any idea of the chain of forwarders.
It does not need to, because it is using proper DNSSEC validation.
Your proposal of using transport security implies your node can always
talk to any worldwide DNS server. That is not the case in most networks.