Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

Tony Finch <> Mon, 10 October 2016 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DD071295A1 for <>; Mon, 10 Oct 2016 11:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VsLIhleMnoOt for <>; Mon, 10 Oct 2016 11:37:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D367A129591 for <>; Mon, 10 Oct 2016 11:37:37 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 3CC69207E7; Mon, 10 Oct 2016 14:37:37 -0400 (EDT)
Received: from web1 ([]) by compute1.internal (MEProxy); Mon, 10 Oct 2016 14:37:37 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=LtSBDWgbcDpRi50 AqwBZwUPkOks=; b=ePVb3cv5boSkSR2N3MrzsasCRMSyhDTJCDLIsFYG5js+7tI RWsBG+xBdbxrbvE1GGouNVkDnLoJtb1xvWuAWdjL3pWPIsUTR7UHAF5kJDIpTimZ HqVJj1Zl6PxTEkq9+xziaY484Ty6WaLcte7Ez82ZIDCPJQSO6zKMLG9IT9Ss=
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 133E76A63F; Mon, 10 Oct 2016 14:37:37 -0400 (EDT)
Message-Id: <>
X-Sasl-Enc: ftDwweHPNMO/+skVqJezK9pZFOIuA9pRWmyNUcVNFpEC 1476124656
From: Tony Finch <>
To: John Levine <>,
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_147612465717940921"; charset="utf-8"
X-Mailer: Webmail Interface - ajax-cdbff290
In-Reply-To: <20161010181043.38506.qmail@ary.lan>
References: <20161010181043.38506.qmail@ary.lan>
Date: Mon, 10 Oct 2016 19:37:36 +0100
Archived-At: <>
Subject: Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Oct 2016 18:37:40 -0000

John Levine <> wrote:
> >Should we treat synthesis as if the cache is pretending to be an
> >authoritative server?
> Yes, although it's kind of subtle.

Yep, that's kind of why I am suggesting a more detailed spec but also
trying to leave as much as possible to the existing intricate

>  For example, I query for
> You can see that the wildcard is *
> But query for
>        3600    IN      A
>        3600    IN      RRSIG   A 8 4 3600
>       20161211000000
> 20161010180056 31806
> You can see that it's synthesized from a wildcard, but you can't tell
> whether the wildcard was
> * or * or *

Ah, but that is what the label count (4) is for in the RRSIG A. The
QNAME has 5 labels so you know the RRSIG belongs to *, and
you have to work this out in order to validate it.

> That's OK, and I believe it is straightforward for a cache to tell
> what names it can synthesize and what names it can't, but it means
> it'd probably be a good idea to make it clear that if there are other
> names in the wildcard's range, the cache often can't synthesize
> results.

And the rules for authoritative servers say which records you have to
put in the answer, so I think it is enough for the cache to check that
it already has the right ones.

In your examples, the first NSEC covered *.h.g to b.h.g proving that
a.h.g did not exist and could be the result of wildcard expansion. In
the second query, e.h.g is outside that NSEC's range, so although the
cache knows it e.h.g is a candidate for wildcard synthesis, it
doesn't have the nonexistence proof, so it has to query upstream. And
it knows what nonexistence proof it needs from the rules for
authoritative answers.

I think something that might need saying (it probably isn't in the
existing specs) is that the validator should cache the wildcard record
that it retconned from the answer (*.h.g in this example). Or maybe it
is obvious from the fact that it is being used for synthesis :-)

Tony (sorry this is a bit vague and off the cuff).
f.anthony.n.finch  <>  -  I xn--
  zr8h punycode