Re: [DNSOP] ALT-TLD and (insecure) delgations.

Brian Dickson <> Thu, 09 February 2017 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73E721298A3 for <>; Thu, 9 Feb 2017 15:09:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 UhXBNDCWqCA4 for <>; Thu, 9 Feb 2017 15:09:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51235129612 for <>; Thu, 9 Feb 2017 15:09:48 -0800 (PST)
Received: by with SMTP id l66so36546961ioi.1 for <>; Thu, 09 Feb 2017 15:09:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ma7Z8abY/APalx2o0UvySj4vyNrMPwt9pzqhU0V22fA=; b=k/ehqdSKNfL5iQ4V6o3EryNhAVLkjjqgNjyjmmZDhxgQONAqbClxWa6wuzeH2TMRRn +DMetH47N6mgawNk5pxZ1CI7ic58HSiVWVhWFDmiJrQGUgzpespXkRjqTdfIWzx8aJul 7m/IevB4EIwhOJHo9vCTmHLfe9oWwky2fEJx6dyw7hK8m4r2YCmv53cQgNGQw1sJQm51 30xDsJK7mISIfD/ASgYtppElFcRo9QnygCvCd1tJ+ICcnUb+owKqqcyo2El0487Wc7FO LtpudBfNXGNkyGUIZq6qwDVk9xbIo2EY61Jngd+bQJOTEzl6qE5QWFBAdA+2lGax7cY2 UDMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ma7Z8abY/APalx2o0UvySj4vyNrMPwt9pzqhU0V22fA=; b=fKzTioQIJegdTn6EIeMzb63NUuTlmrGjH3p8MnT+8YPruizylivaNfBZL3Qnq323MD 6lcHOlGI9j8Q8VciGuhdNnDOP4ESch0Kr3cS5Z8rnZHGppsqM010+p55BDNs4WdwIWHO +sOJ+yztwhoL/NQCX+QQPBk6ylU24LSrCWcQXGT91iG6W79q0dQAZeel3ZHO1ABF17wD OlgftPWI9zHuH8xobCmXylLlGkAoldSJasekPwc0squmXs310S+yeuKWII+5cUhce+CK 0z4Fc7LmVDxwu3p9RtJVDRg+viAWh6Qi7gompYhtQwnv9onDcgTw4cuQbQiIK++uFsQO EpnQ==
X-Gm-Message-State: AMke39neegQT/wpcA0NFENn28q3+B1fnzowzkMFJ10t2ZbnWgUEWGGiLzE0QrqFjFJrTbjmbl6Nwg0BF2wHpvQ==
X-Received: by with SMTP id y14mr5541455ioi.164.1486681787680; Thu, 09 Feb 2017 15:09:47 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 9 Feb 2017 15:09:46 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Brian Dickson <>
Date: Thu, 09 Feb 2017 15:09:46 -0800
Message-ID: <>
To: Mark Andrews <>
Content-Type: multipart/alternative; boundary="001a113fece2d952b805482113d7"
Archived-At: <>
Cc: " WG" <>, Ted Lemon <>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
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: Thu, 09 Feb 2017 23:09:50 -0000

On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews <> wrote:

> In message <>, Ted Lemon
> writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews <> wrote:
> > > At the moment we have Ted saying that if you want privacy you MUST
> > > also turn on DNSSEC validation and implement QNAME minimisation and
> > > implement agressive negative caching (still a I-D).
> >
> > No, I am _not_ saying that.   I am saying that an unsigned delegation
> > doesn't help with privacy unless you also specially configure your local
> > resolver, and if you are going to specially configure your local
> > resolver, then there are several options for how to do that.   The only
> > reason you need DNSSEC is that if you specially configure your local
> > resolver to lie, then DNSSEC validation will break that.   If you aren't
> > doing DNSSEC validation, you can say any old thing in your local resolver
> > and the stub will believe it.
Suppose a signed delegation for alt, to some widely operated, centrally
managed servers (say, the arpa servers).
Now suppose an unsigned delegation for some other name under alt, such as
"foo.alt", to an empty zone on the same set of servers.

The only difference here is where the unsigned delegation is, and what the
scope of that delegation is.

In this scenario, any local "foo.alt" can lie about the contents of
"foo.alt", because it is outside of the secure delegation chain from the

The only difference is that the delegation is not directly from the root.

Any other name under "alt" would have its existence securely denied, unless
and until a request for an insecure delegation was made and approved.

Is there a problem with this scenario?

> And a signed answer doesn't help unless the recursive server is
> validating (so it can trust the NXDOMAIN) and has QNAME minimimistion
> (to prevent *.alt leaking in the first place) and has agressive
> negative caching (so the answer from the minimised QNAME query get
> turned into a answer for *.alt).
> Now we can put QNAME minimisation into a server.
> Now we can put the code to support agressive negative caching into a
> server.
> We can't force validation to be enabled.
> We need all three things for the privacy leakage to stop.  Any two
> alone doesn't stop it.

There's something I don't understand.

In the case where the local namespace (in your email, that would be "alt",
in my example above, that would be "foo.alt") is not configured, why does
leaking matter? Obviously the real local use case is "won't work - broken
config", and leaking is mostly moot.

In the case where the local namespace is instantiated, the queries won't
leak to the root, so privacy is assured.

Are you saying that leakage when the local namespace is non-existent, is
a/the issue?

I don't agree, if that is what you are asserting.
Queries for "" can't expect privacy, unless they are
using a resolver specifically configured for "foo.alt".
Note that defaulting to providing "", and having the DNAME
to "", would further actually accomplish privacy,
without affecting the local instantiation of "foo.alt" via


> The alternative is to do a insecure delegation and build in a default
> empty zone for alt.  You then have to take steps to break the privacy
> leak by disabling the empty zone.  Additionally it works with all
> existing servers if they just add a empty .alt zone.  It doesn't
> require validation to be enabled.
> It's the difference between defaulting private or not.
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: