Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
Roy Arends <roy@dnss.ec> Wed, 10 January 2024 20:38 UTC
Return-Path: <roy@dnss.ec>
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 2DC9EC151068 for <dnsop@ietfa.amsl.com>; Wed, 10 Jan 2024 12:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
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 64pi6LNhJsi9 for <dnsop@ietfa.amsl.com>; Wed, 10 Jan 2024 12:38:45 -0800 (PST)
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com [IPv6:2607:f8b0:4864:20::1131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 DC539C151064 for <dnsop@ietf.org>; Wed, 10 Jan 2024 12:38:44 -0800 (PST)
Received: by mail-yw1-x1131.google.com with SMTP id 00721157ae682-5e734d6cbe4so38391397b3.3 for <dnsop@ietf.org>; Wed, 10 Jan 2024 12:38:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; t=1704919123; x=1705523923; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=L+lAgnTPak/mOnV5on4myBzx/Z8n5Q/X7BpRbZe6HQY=; b=ackfwSG7VUn1eF69Ou4lf5I45egsemvskv09ugS57hu2miMWWLSaaGcG2hMcH5YqAM /gqeK7QWTXLLNaSfCwRLKjUsuFAvMunHODvlyQ7Xm65RheTpeShKgP3bdRexVhWCmdf7 eQsxcaKOx+DAVKYjS/aHi2Con3T2VFtP4DZiI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704919123; x=1705523923; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=L+lAgnTPak/mOnV5on4myBzx/Z8n5Q/X7BpRbZe6HQY=; b=iMgxmv2LgLNEzl7Fix7V6mLWpfbaRZlbjF/bAZqEIXeeuMWOLSQ4qCJiQfm98SOdVf HkLYcmt7crOl+cKVKyAOljx8hRmE1yncOSGYF7RwNZtlRHf/OyIVgj5LjU2Rg6pA1PLs UP/qegor5bIBSgvvJ1ocP2Rhk0qWecFXiwFNZ0g697K7aQpcanptiw6+0AJrDu6evzPz 0e4B4NUoGgzHIZMEGM3pfru0k9SwvPfZTltoM6MTTrIM+hHPZUhRLjdXnhFD4vgBH/2B 3iAdrTR/0p7QfV+Dfv/cyBz6B8TuwGrFozC9ts4QfrR7/yagF5Fkh0S+B3S+LeIBAmdc mXqA==
X-Gm-Message-State: AOJu0YxGGK98ENx56+F079E/6CGyzvl/gWpi6bzh7c8Qlu1kfKZ0Q5oH AAlSTYfQr1yfnpNHXtYPsZENoxU9ODdqqA==
X-Google-Smtp-Source: AGHT+IG6N6rEGh7QWhQVl4GSmRLMuU8g/b5VzKRbzWq43s3kthB+8k/VKpn9iB2+6+/vOc7AzESuDg==
X-Received: by 2002:a25:c7cd:0:b0:db5:426c:f119 with SMTP id w196-20020a25c7cd000000b00db5426cf119mr212455ybe.20.1704919123144; Wed, 10 Jan 2024 12:38:43 -0800 (PST)
Received: from smtpclient.apple ([78.111.198.85]) by smtp.gmail.com with ESMTPSA id u25-20020a05622a199900b004282dea946fsm2001825qtc.69.2024.01.10.12.38.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2024 12:38:42 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <CADyWQ+FW_9pbQFrOJz7R5BQEdL075wXBc=aZ=mcifqT8fekORg@mail.gmail.com>
Date: Wed, 10 Jan 2024 20:38:28 +0000
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F7DBE9D-02DC-421D-9FF5-2AAAED9F982D@dnss.ec>
References: <CADyWQ+FW_9pbQFrOJz7R5BQEdL075wXBc=aZ=mcifqT8fekORg@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wjrY7hiy-DFDtStAGbV4USqQ58c>
Subject: Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 10 Jan 2024 20:38:50 -0000
> On 9 Jan 2024, at 01:54, Tim Wicinski <tjw.ietf@gmail.com> wrote: > > All > > > This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis > "Initializing a DNS Resolver with Priming Queries" > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ > > The Current Intended Status of this document is: Best Current Practice > > Please review the draft and offer relevant comments. > > For WGLC, we need *positive support and constructive comments*; lack of objection is not enough. > So if you think this draft should be published as an RFC, please say so. > > If you feel the document is *not* ready for publication, please speak out with your reasons. > > > This starts a two week Working Group Last Call process, and ends on: January 22, 2024 Thanks Tim, I support this documents. Furthermore, here are some comments: 2. Description of Priming Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The scenario used in that description, that of a recursive server that is also authoritative, is no longer as common. The term “Priming” is not used in RFC1034. What is used in RFC1034 is the term SBELT ("safety belt” structure), defined in 5.3.2. The reference is more useful when the term SBELT is included. 3.3. DNSSEC with Priming Queries The resolver MAY set the DNSSEC OK (DO) bit. At the time of publication, there is little use to performing DNSSEC validation on the priming query. At the time this document is pulished, all root “published” server names end in "root-servers.net" and the AAAA and A RRsets for the root server names reside in the "root-servers.net" zone. All root servers are also authoritative for this zone, allowing priming responses to include the appropriate root name server A and AAAA RRsets. But, because the "root-servers.net" zone is not signed at the time this document is pulished, these RRsets cannot be validated. “published" A machine-in-the-middle attack on the priming query could direct a resolver to a rogue root name server. Note, however, that a validating resolver will not accept responses from rogue root servers if they are different from the real responses because the resolver has a trust anchor for the root and the answers from the root are signed. Thus, if there is a machine-in-the-middle attack on the priming query, the results for a validating resolver could be a denial of service, or the attacker seeing queries while returning good answers, but not the resolver's accepting the bad responses. This is misleading. Not all answers from the root are signed. Some content in the root zone is signed, delegation point NS records are not. This attack will be successful when rogue root-servers change delegation information to unsigned zones. This needs to be more precise. If the "root-servers.net" zone is later signed, or if the root servers are named in a different zone and that zone is signed, having DNSSEC validation for the priming queries might be valuable. The benefits and costs of resolvers validating the responses will depend heavily on the naming scheme used. Not necessarily. This attack will be successful when rogue root-servers change delegation information to unsigned zones (see above) and is not dependent on a naming scheme. 4. Priming Responses A priming query is a normal DNS query. Thus, a root server cannot distinguish a priming query from any other query for the root NS RRset. Thus, the root server's response will also be a normal DNS response. Apologies for sounding pedantic, but what is “a normal DNS query” or a “normal DNS response” ? If there is no definition, maybe the following works for you: The term “Priming” reflects the intent of the resolver. A root server cannot distinguish a priming query from any other root type NS query. The root server's response will therefore be an ordinary DNS response. 4.2. Completeness of the Response At the time this document is pulished, there are 13 root servers. “published" There are 13 hostnames, or root server identifiers. "13 root servers" implies that there are 13 physical boxes. Each has one IPv4 address and one IPv6 address. Not even counting the NS RRset, the combined size of all the A and AAAA RRsets exceeds the original 512-octet payload limit from [RFC1035]. Remove “Not even counting the NS RRset, ”. The remainder of the sentence says enough. In the event of a response where the Additional section omits certain root server address information, re-issuing of the priming query does not help with those root name servers that respond with a fixed order of addresses in the Additional section. Instead, the recursive resolver needs to issue direct queries for A and AAAA RRsets for the remaining names. At the time this document is pulished, these RRsets “published” would be authoritatively available from the root name servers. 5. Post-Priming Strategies When a resolver has a zone's NS RRset in cache, and it gets a query for a domain in that zone that cannot be answered from its cache, the resolver has to choose which NS to send queries to. (This statement is as true for the root zone as for any other zone in the DNS.) Two common strategies for choosing are "determine the fastest nameserver “name server” Hope this helps, Warmly, Roy
- [DNSOP] Working Group Last Call for draft-ietf-dn… Tim Wicinski
- [DNSOP] Priming and RFC 8806 Paul Hoffman
- [DNSOP] typos/language corrections (Re: Working G… Štěpán Němec
- Re: [DNSOP] Working Group Last Call for draft-iet… Paul Wouters
- Re: [DNSOP] [Ext] Working Group Last Call for dra… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for draft-iet… Roy Arends
- Re: [DNSOP] Working Group Last Call for draft-iet… Roy Arends
- Re: [DNSOP] [Ext] Working Group Last Call for dra… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for draft-iet… George Michaelson
- Re: [DNSOP] [Ext] Working Group Last Call for dra… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski
- Re: [DNSOP] [Ext] Working Group Last Call for dra… Paul Hoffman
- Re: [DNSOP] [Ext] Working Group Last Call for dra… Wessels, Duane
- Re: [DNSOP] [Ext] Working Group Last Call for dra… Paul Hoffman
- Re: [DNSOP] Working Group Last Call for draft-iet… Tim Wicinski