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

Mark Andrews <> Wed, 08 February 2017 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E0B5129FD3 for <>; Wed, 8 Feb 2017 11:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aoUKj6oheTe9 for <>; Wed, 8 Feb 2017 11:42:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B0CBA1295A5 for <>; Wed, 8 Feb 2017 11:42:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19F3D34930F; Wed, 8 Feb 2017 19:42:15 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTPS id 05BED160041; Wed, 8 Feb 2017 19:42:15 +0000 (UTC)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7DBD160054; Wed, 8 Feb 2017 19:42:14 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id 7xJfd6o7qvps; Wed, 8 Feb 2017 19:42:14 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTPSA id 036EB160041; Wed, 8 Feb 2017 19:42:14 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id DB02C635DD72; Thu, 9 Feb 2017 06:42:08 +1100 (EST)
To: Ted Lemon <>
From: Mark Andrews <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-reply-to: Your message of "Wed, 08 Feb 2017 10:05:42 -0500." <>
Date: Thu, 09 Feb 2017 06:42:08 +1100
Message-Id: <>
Archived-At: <>
Cc: " WG" <>, Brian Dickson <>
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: Wed, 08 Feb 2017 19:42:23 -0000

In message <>, Ted Lemon writes:
> On Feb 8, 2017, at 1:02 AM, Mark Andrews <> wrote:
> > Which assumes agggressive negative caching.   I'm going to make a
> > realistic assumption that it will take 10+ years for there to be
> > meaningful (>50%) deployment of aggressive negative caching.
> First of all, this probably isn't true, since most of the caches we care
> about are run by network operators, who tend to update more frequently
> for obvious reasons.   But the solution you propose, which causes a
> SERVFAIL, involves a specially-prepared resolver.   So if you get to
> _create_ the problem with a specially-prepared resolver, I get to solve
> it with a differently specially-prepared resolver.   If you want queries
> to .alt not to leak, you have to preload your cache with a proof of
> nonexistence for .alt, and you have to keep it up to date.   This is not
> terribly difficult to arrange.
> >> Leaking a query to .alt is harmless.
> >
> > Is it?  What reports are we going to see over the next 20 year of
> > DITL data on *.alt.
> How is that relevant?   Suppose we don't create .alt, and instead people
> just pick random top-level domains for their experiments, as they do now.
>   Will the number of bogus queries to the root be greater, or fewer?
> Furthermore, queries for .alt are legitimate, in just the same way that
> queries for .com are.   They just have a different answer.

Me, I'm trying to prevent the SERVFAIL issues the IETF has created for
.onion.  In particular this from RFC7686

   4.  Caching DNS Servers: Caching servers, where not explicitly
       adapted to interoperate with Tor, SHOULD NOT attempt to look up
       records for .onion names.  They MUST generate NXDOMAIN for all
       such queries.

Without .onion being a insecurely delegation this results in SERVFAIL
or BOGUS being returned for .onion named when validation is performed
by any validating software that is not RFC7686 aware.

Nameserver vendors have a choice.  Follow RFC7686 and have their
clients get a answer that they know cannot be validated or ignore
this clause and pretend that RFC7686 has never been written so that
their client get a validatable answer.  Should the IETF have put
Nameserver vendors in this position?

At this stage we have not yet implemented this clause in BIND.  We
are aware of RFC7686 and at some point someone will complain that
we don't implement this.  At that point we will point out to them
that this results in SERVFAIL or bogus being returned.

Note all through the debate about .onion I raise this issue.  Go
look at the archives.

Now draft-ietf-dnsop-alt-tld-07 has almost identical wording

   4.  Caching DNS servers SHOULD recognize these names as special and
       SHOULD NOT, by default, attempt to look up NS records for them,
       or otherwise query authoritative DNS servers in an attempt to
       resolve these names.  Instead, caching DNS servers SHOULD
       generate immediate negative responses for all such queries.

This clause results in BOGUS or SERVFAIL being returned to the DNS
application if there is a validator in the return DNS path between
the caching DNS server and the application.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: