[dns-privacy] IETF 116 hackathon on ADoT unilateral probing
Stephane Bortzmeyer <bortzmeyer@nic.fr> Wed, 29 March 2023 08:55 UTC
Return-Path: <stephane@laperouse.bortzmeyer.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1DBC159A1D for <dns-privacy@ietfa.amsl.com>; Wed, 29 Mar 2023 01:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.644
X-Spam-Level:
X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EemPRvBXuHa7 for <dns-privacy@ietfa.amsl.com>; Wed, 29 Mar 2023 01:55:55 -0700 (PDT)
Received: from ayla.bortzmeyer.org (ayla.bortzmeyer.org [92.243.4.211]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEAEC1522D7 for <dns-privacy@ietf.org>; Wed, 29 Mar 2023 01:55:54 -0700 (PDT)
Received: by ayla.bortzmeyer.org (Postfix, from userid 10) id 362C9A00E2; Wed, 29 Mar 2023 10:55:52 +0200 (CEST)
Received: by smoking.sources.org (Postfix, from userid 1000) id 2DEF51BA2071; Wed, 29 Mar 2023 17:53:19 +0900 (JST)
Date: Wed, 29 Mar 2023 17:53:19 +0900
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: dns-privacy@ietf.org
Message-ID: <ZCP8f+TCYKStQwBv@laperouse.bortzmeyer.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Transport: UUCP rules
X-Operating-System: Ubuntu 22.04 (jammy)
X-Charlie: Je suis Charlie
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/WnxQNZYOVUPC-hNd5gazSzfl2Hc>
Subject: [dns-privacy] IETF 116 hackathon on ADoT unilateral probing
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2023 08:55:59 -0000
[Already sent on the list but, apparently, some people missed it and asked for it to be in its own thread.] Following the work done at the DNS table, during the hackathon: * PowerDNS Recursor implements unilateral probing (but not *this* unilateral probing, it differs from the draft, see the questions later) and it works for existing zones, whether they have all their authoritative name servers DoT-enabled, only some, or not at all. No problem was observed. * Unbound implementation is not ready, but I let Yorgos elaborate on this point. Some questions were raised about the draft, giving the experience with PowerDNS Recursor: * If the ADoT server replies but the reply indicates an error, such as SERVFAIL or REFUSED, should the resolver retries without DoT? PowerDNS recursor does it, but it seems it would make more sense to accept the reply, and just to remind system administrators that port 853 and 53 should deliver consistent answers. The draft seems clear on the first point (as long as there is a properly formatted DNS request, regard the server as DoT-enabled) but not on the second (no clear reminder for authoritative name servers). * What should be the criteria to select an authoritative name server to query? Should we prefer a fast insecure server or a slow encrypted one? The draft does not mention it, because it is local policy. (PowerDNS recursor has apparently no way to change its default policy, which is to use the fastest one, DoT or not.) The draft does not mandate such a knob in the authoritative server, again, IETF typically does not tell endpoints how they have to be configured. * Should we do lazy probing, like PowerDNS Recursor does, or use the more eager "happy eyeballs" algorithm of the current draft? Also, currently, regarding the possible warning to system administrators about the need for 53 and 853 to be in sync, we currently find in the wild servers that implement different services on the two ports. See for instance ns1.eu.org (authoritative for eu.org) or ns1-dyn.bortzmeyer.fr (authoritative for dyn.bortzmeyer.fr). Both have authoritative on 53 and an open resolver on 853. Should we explicitely ban this practice? You may find some details of this work during the hackathon on my article: https://www.bortzmeyer.org/hackathon-ietf-116.html
- [dns-privacy] IETF 116 hackathon on ADoT unilater… Stephane Bortzmeyer