IETF Logo Mail Archive

Re: [Add] TTL of resolver.arpa

Paul Wouters <paul@nohats.ca> Wed, 22 December 2021 17:06 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A033A0A82 for <add@ietfa.amsl.com>; Wed, 22 Dec 2021 09:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d0iwCsct-NF for <add@ietfa.amsl.com>; Wed, 22 Dec 2021 09:06:22 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792F13A0A7E for <add@ietf.org>; Wed, 22 Dec 2021 09:06:22 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4JK08n4KQxz7Yn; Wed, 22 Dec 2021 18:06:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1640192777; bh=MsygPmmZeLOvs+u1vpEf0WW3FoM68pAbgzR1QhdMaHE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KOZEb+GuOjyLqE6cHQ9PI6I74fvvCvXA78TH7LHsXBdpSEndBSw1LHAVQIkGyK0OD LZaDaIUNcRZBJGqQLkkQ67DHeo+RWTwwBuxBXYro1MTLWj4H/Icoa16qLMgVe7z50a My6g66pyq7rIoaM81wHDYKA6NN8NcAA+Fq8twsx4=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6B58LEoN2irC; Wed, 22 Dec 2021 18:06:16 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 22 Dec 2021 18:06:16 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 72CB41D761D; Wed, 22 Dec 2021 12:06:15 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 71CE61D761C; Wed, 22 Dec 2021 12:06:15 -0500 (EST)
Date: Wed, 22 Dec 2021 12:06:15 -0500
From: Paul Wouters <paul@nohats.ca>
To: Eric Orth <ericorth=40google.com@dmarc.ietf.org>
cc: Daniel Migault <mglt.ietf@gmail.com>, ADD Mailing list <add@ietf.org>
In-Reply-To: <CAMOjQcG7uHxzMFyGuH8RLY1i6aJ2gjWZWv3L7VQms_gDFJ6BqQ@mail.gmail.com>
Message-ID: <dd7bd95-759a-29b5-d387-cc6b296bec2c@nohats.ca>
References: <CADZyTkmMKJ=shoWZxEUeyt8vNAs6SWHOr9BGkr-+63=Gcv934w@mail.gmail.com> <CAMOjQcG7uHxzMFyGuH8RLY1i6aJ2gjWZWv3L7VQms_gDFJ6BqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/dI0b8PCUdaYtkdbkpHuNeY6P_AU>
Subject: Re: [Add] TTL of resolver.arpa
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Dec 2021 17:06:28 -0000

On Wed, 22 Dec 2021, Eric Orth wrote:

> Many clients already do stuff like clear the cache on network change

which is wrong of course, because a roaming phone or laptop would leave
a very district dns lookup trail based on joining a network with an
empty cache and many browser tabs open.

> or DNS config change, so such a policy is unnecessary for them.

but for them, harmless.

>   And when the network and resolver haven't changed, it is still undesirable for the
> client to poll that resolver more frequently than the TTL, so using their cache implementations is the obvious way for clients to implement this desired
> behavior.

I agree that "network change" could be used to trigger the cache removal
of resolver.arpa specifically. Athough, I don't really see why using TTL
0 is a problem. I don't think the TTL means the resolver information is
valid for that TTL time. TTLs refer to cachability of DNS records, and
must not be used as time validity tool for third party information or
services, such as an encrypted DNS resolver service. Or rephrased, if
you would use it like that, and your DHCP server hands out resolver.arpa
with TTL 7200, the DHCP server would be commiting the DNS resolver to
be operational on the IP for 2hours and it may not be shut down. That
seems wrong to me as the DNS resolver and DHCP server have no direct
communication link (or protocol) to exchange that information.

Paul

> On Wed, Dec 22, 2021 at 9:45 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
>       Hi, 
> 
> I am wondering if some additional text is not needed regarding the TTL of the _dns.resolver.arpa RRset. As resolver.arpa is not owned by anyone,
> this information should not be cached. If one device is changing network for example, we should make sure the mobile will not consider the
> resolver.arpa response performed on a previous network. Similarly, when a dns client performs simultaneous discovery on different resolvers. Should
> we recommend/mandate the DNS client to set this TTL to 0 and not cache the response ? 
> 
> _dns.resolver.arpa  7200  IN SVCB 1 doh.example.net (
>         alpn=h2 dohpath=/dns-query{?dns} )
> 
> Yours, 
> Daniel
> --
> Daniel Migault
> Ericsson
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
> 
> 
>

v2.23.0 | Report a Bug | By Email