Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt

"Wessels, Duane" <dwessels@verisign.com> Wed, 18 October 2017 22:27 UTC

Return-Path: <dwessels@verisign.com>
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 31A751321A1 for <dnsop@ietfa.amsl.com>; Wed, 18 Oct 2017 15:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 ypDomy0ftAHO for <dnsop@ietfa.amsl.com>; Wed, 18 Oct 2017 15:27:55 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CC2132193 for <dnsop@ietf.org>; Wed, 18 Oct 2017 15:27:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3366; q=dns/txt; s=VRSN; t=1508365675; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=AqDhZvgFvErjSU8EocXnBUbxdB1hEO6QzDh8VYFonGw=; b=OI7Vh6og/0pWjp0lsIDjHzw4OOSDznkioiw+o7CVoQzvfEPj0xxM7hhO qfJNzDHMzWrX5n1R1Qcbviza3iXBWbI8+ZPYAB60QKNqnBazmnxQUxw74 RWvRCEENZLRR/KUXo4qQS7OPDCiuSSIqzJYg/rW3raWGsRV11LPuYlpf3 iwBZEs++pFME0AxN4o9teupiEIVF2LC1ZwbB3AA/89x/clF/TGtj3Qiv6 zub8rwJJt4BHJpb6aZHoKeeUWiIKVcIFJHIJDTu3IuBp411AJQk5jbZr+ dqm1EiPuFARXdKdJy/SNNd0f9KbFpx19efn0aCcE6V6NSp4PC6jgpTNPs g==;
X-IronPort-AV: E=Sophos;i="5.43,398,1503360000"; d="scan'208";a="2800571"
IronPort-PHdr: =?us-ascii?q?9a23=3AAOtsrhUB3S2lFR7LzGtcXA/MkgDV8LGtZVwlr6E/?= =?us-ascii?q?grcLSJyIuqrYbBCOt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2y?= =?us-ascii?q?cZYBD/YPM+hboYnypVoOogexCwajH+7v1iZIhnrq0aEmz+gtDwfL1xEgEdIUt3?= =?us-ascii?q?TUqc34OKkSXu+r16nI1ivMb/dN2Tvl9YPGfA0hruuKXb1uf8ba1E4iGB7Lj1qO?= =?us-ascii?q?sozlJC2a1uAWs2WA8epvS/ivi288qwFwrTivwN0ghZXOhoIQ013J8zhyzogyJd?= =?us-ascii?q?29UkF7YNikHYNRty6EK4t2TNkuQ2ZyuCY1zLANpJ21fDASxZg62xLTceGLfoqG?= =?us-ascii?q?7x75SeqcITl1iGh7dL+wiBu+6VWsxvHmWsWp0ltGsjBJnsTDu30OzRDf98uKR/?= =?us-ascii?q?1g9Um7wzmPzRrc6uRcLEAxkqrUNoAuz6YrlpoWrUTDBij2mFjqjKOOdkUr5Oyo?= =?us-ascii?q?6+P/b7r9vJ+cMZJ4igXxM6QrgMO/AOA4Mg8TX2iH5eiwyafv/VPnT7VQj/02ia?= =?us-ascii?q?jZsJ/cJcgBuqG5BApV3p4i6xa5ETimzMwVkWQbIF5fZR6KjYbkN0vTLP34A/qz?= =?us-ascii?q?mUqgnThkyvzeO73uGJTNLnzNkLf7erZ97lZRxxc9zN9B/JJUEa8OIPboWkLqqt?= =?us-ascii?q?zXEAU5Mw2vw+bmB9V90JkSVn6IAq+cKK/Sq0OH5vozI+mQY48YoCvyK/4+5/7p?= =?us-ascii?q?lX80gl4dcre13ZsZcny4Ge5mI0rKKUbr19sHCmAS9jURBLjmjkaFSRZSamq8Ga?= =?us-ascii?q?Um6WdoJpihCNKJeY22m7GFx2PzMoBfYG0MQgSADnrzbIiAQN8SZTiTOc5ulHoP?= =?us-ascii?q?Ur33GNxp7g2nqAKvk+kvFeHT4CBN8Mu7jNU=3D?=
X-IPAS-Result: =?us-ascii?q?A2GPAABv1OdZ//SZrQpcGQEBAQEBAQEBAQEBBwEBAQEBFAE?= =?us-ascii?q?BAQEBAQEBAQEBBwEBAQEBhBiBFQeOEpEMJXuVOIINBwoYC4UYAoU4GAEBAQEBA?= =?us-ascii?q?QEBAQEBAoEQgjgkAQ1GLAEBAQEBASYBAQEBAQEjAj4sAQEBAQIBAQE4NBALAgE?= =?us-ascii?q?IDQseECcLJQIEE4oYGK06iyUBAQEBAQUBAQEBAQEBASCDL4NZgWkrC4JENYReE?= =?us-ascii?q?RaDQoIyBYoQhziBa44SBgKHXo8hXYUZiw6VRgIECwIZAYE5H4IUehUfKi0BgjY?= =?us-ascii?q?JhFZ2iCaBM4ERAQEB?=
Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01 [10.173.152.255]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v9IMRpdi021366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dnsop@ietf.org>; Wed, 18 Oct 2017 18:27:51 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Wed, 18 Oct 2017 18:27:51 -0400
From: "Wessels, Duane" <dwessels@verisign.com>
To: dnsop WG <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt
Thread-Index: AQHTSGBVN06d/np28Eev9GJJu8TEkQ==
Date: Wed, 18 Oct 2017 22:27:50 +0000
Message-ID: <609A6D8D-DF63-4000-8928-23968C2518D1@verisign.com>
References: <149592096439.3966.11385984990945858242@ietfa.amsl.com>
In-Reply-To: <149592096439.3966.11385984990945858242@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <988F07D1A4FC2840B4F64439A973D9EC@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Pc8iGemfjO2FsNV-MNd5n6eKvUc>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 18 Oct 2017 22:27:57 -0000

I have a couple of questions about the text in 3.1 around TTLs and caching:

> Address records cached locally MUST have a limited TTL.  The initial TTL
> for locally-cached address records MUST be set to the lesser of the ANAME

Reading this reminds me of the way that Unbound works with respect to its
cache-max-ttl.  Quoting the documentation:

     cache-max-ttl: <seconds>

            Time to live maximum for  RRsets  and  messages  in  the  cache.
            Default  is  86400  seconds  (1  day).  If the maximum kicks in,
            responses to clients still get decrementing TTLs  based  on  the
            original  (larger)  values.   When the internal TTL expires, the
            cache item has expired.  Can be set lower to force the  resolver
            to query for data often, and not trust (very large) TTL values.

In other words, Unbound uses the original TTL but removes the data after
cache-max-ttl, which might be shorter.  

Might it not also be acceptable (desirable?) to do the same for aname?  I think
it would mean that the A/AAAA records are cached similarly by both aname-aware
and aname-unware recursive name servers.


> TTL and the TTL of the address records retrieved from the ANAME <target>.

Perhaps "...and the TTLs of all the address records..."?



> The local TTL MUST count down, just as it would in a conventional resolver
> cache.  Records with an expired TTL MUST NOT be used to answer address
> queries until refreshed with a new query to the ANAME <target>.

That only says what not to do.  How should the server respond if the
locally-cached address records cannot be refreshed?  SERVFAIL?  whatever
draft-serve-stale says?

DW


> On May 27, 2017, at 2:36 PM, internet-drafts@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
> 
>       Title           : Address-specific DNS Name Redirection (ANAME)
>       Authors         : Evan Hunt
>                         Peter van Dijk
>                         Anthony Eden
> 	Filename        : draft-ietf-dnsop-aname-00.txt
> 	Pages           : 10
> 	Date            : 2017-05-27
> 
> Abstract:
>  This document defines the "ANAME" DNS RR type, to provide similar
>  functionality to CNAME, but only redirects type A and AAAA queries.
>  Unlike CNAME, an ANAME can coexist with other record types.  The
>  ANAME RR allows zone owners to redirect queries for apex domain names
>  in a standards compliant manner.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-aname-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop