[DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat Dnsdir review
Tobias Fiebig <tobias@fiebig.nl> Fri, 09 January 2026 11:21 UTC
Return-Path: <tobias@fiebig.nl>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0D0ADA54EACB; Fri, 9 Jan 2026 03:21:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Level:
X-Spam-Status: No, score=-4.399 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_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=fiebig.nl
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2A7Gk4PMYKa; Fri, 9 Jan 2026 03:21:41 -0800 (PST)
Received: from mail.aperture-labs.org (mail.aperture-labs.org [195.191.197.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 84B2AA54EAC2; Fri, 9 Jan 2026 03:21:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiebig.nl; s=key01; t=1767957699; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ycZKYq9u0pMOzfcdz87WwYQwT6DiDvvlHItsmWUJf/A=; b=I3yGvoNgRfQlI/phBzwIp6NtWvkrVY4aI4Vpn9dnP9fN+E1Um4JsIfN+frQ0F5wRAZabI3 MB0RZKr8+L7yc36N1wkRuS/EUaMCLc7JXC7I/sBAc2x73tvDZ4GOi4IyPUxrJMitS9QG6a PBL7QGgGZeRLLplc3zxrye/BAn6IS108t6J2jFHXRpYngagEyicl85jTrDzh2n6SxGw0DQ xpADRxU05QCYMVZHrx3yXRZAvtHtdj4xilv0vWc1mkFYOcHF9dkTNSdCpKXALwBTwLS6MO KsK2vLY5MuAIHdjmlgANvScoKtZv9rInFuDrIV08lISXUXLrs00GqgTuIQ8roQ==
Received: by mail.aperture-labs.org (OpenSMTPD) with ESMTPSA id 8a9aaacc (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) auth=yes user=tobias@aperture-labs.org; Fri, 9 Jan 2026 11:21:39 +0000 (UTC)
Message-ID: <337f1ed7bbef614b836872abb3ee2860aea34061.camel@fiebig.nl>
From: Tobias Fiebig <tobias@fiebig.nl>
To: Joe Abley <jabley@strandkip.nl>
Date: Fri, 09 Jan 2026 12:21:38 +0100
In-Reply-To: <D1756F96-A565-4A2B-92FC-B09180ACF69B@strandkip.nl>
References: <13152225d5175dc923a7081792cc38b7907537a5.camel@fiebig.nl> <D1756F96-A565-4A2B-92FC-B09180ACF69B@strandkip.nl>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2
MIME-Version: 1.0
Message-ID-Hash: EYUQXP7IZWBRPJJXFDGY2363MLXFRS2R
X-Message-ID-Hash: EYUQXP7IZWBRPJJXFDGY2363MLXFRS2R
X-MailFrom: tobias@fiebig.nl
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, ops-ads@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Reply-To: tobias@fiebig.nl
Subject: [DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat Dnsdir review
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rvG6txNWeBvkQZd0HG2pPbwDNMA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Hello Joe,
> This is not true ("safely assume"). There is a complex graph of
> actors between stub resolvers and authority servers in the real
> world, many of which originate queries with RD=1.
>
> For example, ISP resolvers which forward queries to public resolvers
> with RD=1 are commonplace. Home gateways that receive queries from
> devices within the home, and forward to other upstream resolvers with
> RD=1 following a cache miss are commonplace. These are not niche
> configurations.
>
> I have not read your proposed changes to the text to address the
> comment from Geoff that prompted your response above, but if it is
> based on the "safe assumption" above you may want to revisit it.
The text now reads:
"Finally, when responding to recursive queries, i.e., a query with the
RD bit set <xref target="RFC1035"/>, a DNS resolver SHOULD follow..."
It is not relevant what kind of configuration sent the query. If this
was libc, a local dnsmasq, a dnsmasq on a CPE, an ISP's recursive
collecting all the queries from all CPEs and forwarding them to quad
1/8/9 etc.
It is about handling recursive queries. And if the RD bit is set, the
query is recursive, and is not being recursed by the client who sent
the query, but the recursive receiving it is supposed to recurse it.
With best regards,
Tobias
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tobias@fiebig.nl
Pronouns: he/him/his
- [DNSOP] draft-ietf-dnsop-3901bis-10 telechat Dnsd… Geoff Huston via Datatracker
- [DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat … Tobias Fiebig
- [DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat … Geoff Huston
- [DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat … Tobias Fiebig
- [DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat … Joe Abley
- [DNSOP] Re: draft-ietf-dnsop-3901bis-10 telechat … Tobias Fiebig