[DNSOP] Re: DNSOPDNSOP[Ext] Pushing items out of cache

Wes Hardaker <wjhns1@hardakers.net> Thu, 12 March 2026 04:14 UTC

Return-Path: <wjhns1@hardakers.net>
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 B58ABC8AC84B for <dnsop@mail2.ietf.org>; Wed, 11 Mar 2026 21:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=hardakers.net
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 AwazPens9lOS for <dnsop@mail2.ietf.org>; Wed, 11 Mar 2026 21:14:31 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 36309C8AC842 for <dnsop@ietf.org>; Wed, 11 Mar 2026 21:14:31 -0700 (PDT)
Received: from localhost (178-196.icannmeeting.org [199.91.196.178]) by mail.hardakers.net (Postfix) with ESMTPA id 8D3F820670; Wed, 11 Mar 2026 21:14:22 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 8D3F820670
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1773288864; bh=vfJm5Oigr0ZsjOdqM7iyzH+cmjH1c4GS5mlbOKTytKQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=eAZFZG0ClfSIDm85u3jCgHVT/V5YVWCc7szQiP2FyxVRSfLQw6hVwRjYx67Kv7078 +bUsdgzubBjL32B8/8haSK4hJ52U8rittbv6dInyMnpQ4hkbumyM+wAdrmqqf9cYxw s4U6/iHJQnENEiAZE/UIJLjMsOq9iBPFB/iPJgdQ=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Ray Bellis <ray@bellis.me.uk>
In-Reply-To: <5d9616ad-cc0e-42ca-ace8-7a4f25a5e17f@bellis.me.uk> (Ray Bellis's message of "Wed, 11 Mar 2026 15:23:46 +0000")
References: <m1vyEK3-0000MpC@stereo.hq.phicoh.net> <3FAADA8F-8875-4170-94E6-BAB86D00357F@strandkip.nl> <m1eclyujhp.fsf@narrans.de> <ybla4wlo98k.fsf@wx.hardakers.net> <m1pl5eu0qj.fsf@narrans.de> <m1vzCBI-0000MbC@stereo.hq.phicoh.net> <m1ldg2tspq.fsf@narrans.de> <m1vzWKF-0000MbC@stereo.hq.phicoh.net> <ybl5x75l2ji.fsf@wx.hardakers.net> <m1vzYAc-0000NHC@stereo.hq.phicoh.net> <4A5C6EE2-C31E-4A60-994E-1E6783AD1010@icann.org> <m1vzcx2-0000S4C@stereo.hq.phicoh.net> <DAC83892-60BA-464E-8463-EBC26B15DBAA@icann.org> <m1vzfNA-0000MxC@stereo.hq.phicoh.net> <yblpl5aiwtt.fsf@wx.hardakers.net> <5d9616ad-cc0e-42ca-ace8-7a4f25a5e17f@bellis.me.uk>
Date: Wed, 11 Mar 2026 21:14:19 -0700
Message-ID: <yblbjgtit0k.fsf@wx.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Message-ID-Hash: 4TBWMFB3YEL27TNVZT7VWZ6MIH4YR6ZX
X-Message-ID-Hash: 4TBWMFB3YEL27TNVZT7VWZ6MIH4YR6ZX
X-MailFrom: wjhns1@hardakers.net
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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: DNSOPDNSOP[Ext] Pushing items out of cache
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kljD4Hg-LSKDcykXYzdJCecOL80>
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>

Ray Bellis <ray@bellis.me.uk> writes:

> FTR, BIND's mirror zone implementation does not entirely satisfy this.
> 
> With a mirror zone for the root configured, a query for `. SOA` will
> always return with the original TTL of 86400, instead of a decreasing
> value returned from cache.  Queries for a TLD's parent side records
> (e.g. DS) also return a fixed TTL.

IMHO, that still meets the criteria.  Can you explain why you think it
may not?

If a client queries a bind server now it gets back a TTL that is the
same as the original, sure...  but that's always possible anyway.

I'd be happy to add text that you think would help to allow this
behavior to be considered compliant.

I think the thing I didn't talk about that probably does need to be
discussed is the AA bit.  Bind with my localroot (isi) config turns it
into an authoritative mirror, and thus the AA bit can be set.  Is this a
good thing or a bad thing?

-- 
Wes Hardaker
Google