Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Ben Schwartz <> Thu, 30 July 2020 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FD903A0A8F for <>; Thu, 30 Jul 2020 15:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZVGp0FEGhSeW for <>; Thu, 30 Jul 2020 15:25:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24C103A0A88 for <>; Thu, 30 Jul 2020 15:25:18 -0700 (PDT)
Received: by with SMTP id f1so25731345wro.2 for <>; Thu, 30 Jul 2020 15:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZrtxibSMom9Q5jqLBoncE51ubLp+47Pvr81PL6y4WzY=; b=r+mOvg3HtIVvRQpCpkP+NXPLR5ebtLFs8q2YrTusnmRnlARm7M7b2JvscXLh4WAR1R +WGJZCFeIW+PGTwhq5/JqHwnKCNgsgtuGoyHV0PLJsTrTLXuKixXervCE33s04nON1H+ NgpXMelteYeGlq3pWnS6tFAwfNKQhRU80/pWfg4Z8ltvATDbkHA2CoUwFt7rjR5AlWcb yG1BHBF9Rn5UWJGD7OHBc2V1i6V5CPIhz/BkiGHMW99CDoQrEyE/idhDNa5PHTj6Ti3b dJns6asqrsQ72KGWZCPZ8Sx0z0ro5AxZxnIvxQCwP4WiROFsMvKwD7FlxK1wgzjaJ/lV jooQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZrtxibSMom9Q5jqLBoncE51ubLp+47Pvr81PL6y4WzY=; b=fjNNlFjrxaa5GYXQ9AZbyHUvSJXqfnkjvqGHV/hCtD5RUO2I56doHs6pZoRyM0wCrf nCVG6+GGMgXFdB+GgY1YHIGneqXUxHYfCZvVN8B4UE6sn35+YNGzF0NJuIwrCwODtWFg ZcVSZ8AFlArBYNJcb7YJzp9Vi6E3qLJoAGak57RrpkWr5HLlKbYv+1aNh76ZRQP056XK ZfBGnJKncLoKzTAa9VSp2iphQe530LCMz4z1VsJv8xc+ucsVX1YJ6/MgO4MuQ/DTcLrK wxet8wuxJd1iupMwrgIml1+u3PpSZh6qEbB0uMHqeze+m2J5A8ncsYKT3nGoAl8yIR0l 2HgA==
X-Gm-Message-State: AOAM532VYgk7E/tYe2fTSuHCmi4NzfIiJix/AI5iL/dts3is9m2PBpsR uHXxqHYWTe6r3XtI7t43qRX+uqY59iB2G658i4b0Hg==
X-Google-Smtp-Source: ABdhPJzw35hxL511wAmrnDKpKOT26kaiRzke2U3Q3ggq0VDSX629ZDBtWpuVKjpueq0EYGfcwWKNAZkD6RgaADShvnU=
X-Received: by 2002:a5d:43c4:: with SMTP id v4mr740067wrr.426.1596147916139; Thu, 30 Jul 2020 15:25:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Thu, 30 Jul 2020 18:25:04 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000095b29705abb0252a"
Archived-At: <>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 22:25:21 -0000

I want to reiterate that I support the goal of this draft.  I just think
the claimed benefits need to be more precise.  I think Petr is right: this
is mostly because we don't agree on what transparency looks like.
Specifically, we need to understand both (a) what transparency logging
requires without this flag and (b) how it is easier with this flag, in
order to compare them and identify the benefit.

Take .org as an example.  Per Joe's description, .org is not
DELEGATION_ONLY, but it is "mostly delegation only".  Knowing this, we can
start transparency-logging the org zone.  The DELEGATION_ONLY flag isn't
needed, and wouldn't substantially help, for this single case.

I think this flag does help overall.  For example, assuming we can make it
usable by some TLDs, I think it is a sufficient indicator that a TLD is
suitable for logging, avoiding the human effort of investigating those
TLDs' practices.  (I also think it greatly reduces the chance of
_accidental_ impersonation, which might be enough justification on its own.)

With or without this flag, I think we'll also want to log many zones that
are "mostly delegation only".  We might even need a different flag that
says "this zone is suitable for logging", or the inverse, but has no effect
on the resolution process.  Alternatively, perhaps those zones can be
curated manually out-of-band, like the PSL.

On Thu, Jul 30, 2020 at 4:28 PM Paul Wouters <> wrote:

> On Thu, 30 Jul 2020, Ben Schwartz wrote:
> >       I do not believe that is correct. The first and foremost purpose
> is for
> >       the bit to signal the parent zone's behaviour in a public way that
> >       prevents targeted / coerced attacks from the parent.
> >
> > I would love to see some more description of these attacks in the draft.
> I'm a bit confused that you think describing that in more detail helps.

>From this conversation, it seems like these attacks are achievable, and are
detectable by logging, with or without the DELEGATION_ONLY flag.  I was
trying to understand if the flag can sometimes _prevent_ the attack, e.g.
when there are cached DS records.  However, a prevention claim requires
much more text on possible attack modes (e.g. can the parent shorten TTLs
to enable the attack?).

> Does the targeted attack still> apply if the recursive resolver does
> QNAME minimization?
> It is unrelated to query minimalization, other than that targetted
> attacks in response to specific queriers is harder.

That seems like an important mitigation.  Does this rely on the attacker
inserting "deep" Additional records?

> From the current text, I'm having trouble understanding why it matters
> whether the attacker has to
> > generate a fake child zone or not (in the absence of transparency).
> The attacker could do the above (or even just present glue pretending
> the is unsigned, thereby leaving out cryptographic traces).
> If it is forced to generate a new DS for his attack to succeed, and they
> are forced to publish this at large (eg because query minimalization)
> then any monitoring of DS records will get them caught.

You said above that this flag "prevents" targeted attacks, but I think here
you are saying that it only _deters_ these attacks, provided that logging
or monitoring is in place.  (I don't really understand the difference
between logging and monitoring.)  I want this deterrence!  I also want to
be precise about the motivation.


> > The draft says that universal logging "would require zone owners to
> expose all their zone data ... thereby
> > introducing privacy implications".  This seems to apply whether or not
> the zone is delegation-only, so DNS
> > resolvers would be violating this proposed privacy principle unless the
> zone somehow indicates that it
> > opts in to logging.
> That statement applied to when we do not have this bit and we would want
> to ensure no queries every violated the implicit delegation-only role.

I don't understand.  What privacy implication would apply to contentful
zones, but not to delegation-only zones?  In my experience, the main
privacy concern expressed by zone owners is about the list of names, not
the content of any records.  (Hence NSEC3, NSEC5, etc.)

If I believe that names under corp.mycompany.example are supposed to be
secret, then presumably I don't want them showing up in public logs due to
an overzealous stub resolver on my network.  Yet there's no reason
corp.mycompany.example couldn't be DELEGATION_ONLY.

Again there is no "submission" of zone data to a log anywhere in this
> system by the authoritative zone operator. I will talk to Wes about
> changing this text.
> >       On an empty DNS cache, I'm quite literally broadcasting the
> largest DNS
> >       fingerprint possible to identify my. My only change at hiding is
> to have
> >       a local DNS cache.
> >
> >
> > If you move IP addresses without wiping your DNS cache, your cached DNS
> entries become a supercookie by
> > which a distant server can reidentify you across the network.
> That is why you use prefetching and ideally the resolver you are using
> also uses prefetching, so that hot data (eg data that is regularly
> queried for while it is still in the cache) is pre-fetched before
> expiry. And no direct IP link exists between you and the auth server.

I don't think that helps.  A website at can easily put $ into your local (and recursive) cache, with long TTL,
CNAMEd to  Then, it can remove $userid from its zone.  From
now on, when a client connects via a different recursive, can
check if it's you, by telling the client to connect to $
If that works, you must be the same user.  (Fancier variations can scale

This is off-topic except to say: the caching recommendation is not obvious,
is not necessary, and should go in a different draft (if it is indeed the
group's consensus).