Re: [DNSOP] Verifying errata 5316 against RFC1034.

Mukund Sivaraman <muks@isc.org> Sun, 01 April 2018 18:28 UTC

Return-Path: <muks@isc.org>
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 99F63126BF0 for <dnsop@ietfa.amsl.com>; Sun, 1 Apr 2018 11:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 60OS37A-U0uf for <dnsop@ietfa.amsl.com>; Sun, 1 Apr 2018 11:28:20 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 14BE31201FA for <dnsop@ietf.org>; Sun, 1 Apr 2018 11:28:20 -0700 (PDT)
Received: from jurassic (unknown [182.156.109.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 21B6232C06F1; Sun, 1 Apr 2018 18:28:15 +0000 (UTC)
Date: Sun, 01 Apr 2018 23:58:07 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Warren Kumari <warren@kumari.net>
Cc: dnsop <dnsop@ietf.org>
Message-ID: <20180401182807.GA14467@jurassic>
References: <CAHw9_iJugi-bucEqLA=wsgf5J7C7BDN2zqHsNeHuckx2QAkpiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHw9_iJugi-bucEqLA=wsgf5J7C7BDN2zqHsNeHuckx2QAkpiw@mail.gmail.com>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MjaWvMb1qn77M8R1LvCyit-qSmc>
Subject: Re: [DNSOP] Verifying errata 5316 against RFC1034.
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: Sun, 01 Apr 2018 18:28:22 -0000

On Sun, Apr 01, 2018 at 01:33:17PM -0400, Warren Kumari wrote:
> Can folk help me understand what should happen with this errata?
> W

To elaborate further:

IMO there's no argument against caching if the cached record set (with
wildcard owner name) was not used in synthesis of RRs. I suspect RFC
1034 language was written to prevent that, not the actual caching
itself.

Caching takes place not just by BIND, but Unbound as well and does not
cause problems, so the stronger requirement is unnecessary and ought to
be re-worded.

That is.. unless there is something I've missed. ;) What else is the
problem in caching wildcard records?

> Note that if behaviors have changes, and implementations should now
> cache the record, then we need to document that in a -bis (or similar)
> document.

I agree about this in the scope that we even allow some synthesis with
DNSSEC now in RFC 8198.

But the errata is still for the 1987 document, i.e., as it was back in
time. There doesn't seem to be any sense in having this requirement and
implementations ignore it anyway.

		Mukund