Re: [DNSOP] my dnse vision

Phillip Hallam-Baker <> Mon, 10 March 2014 18:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F3FF01A03FC for <>; Mon, 10 Mar 2014 11:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bvL4mrjh3yEf for <>; Mon, 10 Mar 2014 11:29:03 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22f]) by (Postfix) with ESMTP id 72F241A0488 for <>; Mon, 10 Mar 2014 11:29:03 -0700 (PDT)
Received: by with SMTP id y1so4871099lam.20 for <>; Mon, 10 Mar 2014 11:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XcJMWvdl0Ce7K/wfJAcnQciuRPuJw/gHnw68OoIhoWM=; b=E9NESohIHaioM0dMwca+VaQLu/Sj+6gLeg7OEW22l6iiA5l0uQMQPJrvw+8q0Gnexc JkcKVjh6r3HnU9e2mUeWMaZOpNvmi279M9ankZ40G9oXiLUQqRjRc7eY0cqdJUvptkAe V2A1co4NTOdaZorXpooJTx4jCo4FU5aZskCmxtiOGjAc2ZO4zF9kBnrdl+GKl/JX7CfL Wz84lp64p+ABmqES8NwLb0pkU1IX7YWXuWebnBJYRwYzardyNXxty4/XIfH14tLT+uT9 o3VeZc+CYHbStoHDZMmJ2DECpufOZmjNHPuGmO7d6AmaDqDtmanhuBqfW4eZJtTBccIe gnIg==
MIME-Version: 1.0
X-Received: by with SMTP id r6mr2614879lal.32.1394476136965; Mon, 10 Mar 2014 11:28:56 -0700 (PDT)
Received: by with HTTP; Mon, 10 Mar 2014 11:28:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Mon, 10 Mar 2014 14:28:56 -0400
Message-ID: <>
From: Phillip Hallam-Baker <>
To: Tony Finch <>
Content-Type: multipart/alternative; boundary=001a11c36780caab8504f444c6c2
Cc: "" <>
Subject: Re: [DNSOP] my dnse vision
X-Mailman-Version: 2.1.15
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 Mar 2014 18:29:06 -0000

On Mon, Mar 10, 2014 at 1:44 PM, Tony Finch <> wrote:

> Phillip Hallam-Baker <> wrote:
> >
> > First off it means that if the recursive is being used in discovery-only
> > mode it can simply pass data from the authoritative to the stub without
> > checking the DNSSEC chain.
> If the recursive server is cacheing it needs to do DNSSEC validation to
> protect its cache from poisonous authorities.

But that would be an offline activity rather than within the response loop
to service the request from the stub.

> Resolver is connecting to an authoritative to make a request
> > to answer a query from a stub (i.e. this is not a
> > pre-fetch).
> >
> > Resolver has no session key on file so it sends the request in plaintext.
> This leakage is bad expecially for recursors with few users and / or
> queries for infrequently visited domains.

If a Russian citizen is visiting and the authoritative for that
zone only has that entry and nothing else, then traffic analysis is going
to give away the request subject.

That is just something we have to live with, lessons in not being seen and
all that.

> > It can however be alerted to support for the security protocol in the
> > DNSSEC information for the zone.
> This is a bad idea because it makes partial deployment difficult - e.g.
> staged roll-out of encryption. DNSSEC information is per-zone but
> encryption has to be per-server.

I can't see the point of a partial rollout of encryption at an
authoritative. But worst case it just means that the client is going to
assume the service does not support encryption until it sees an EDNS record
saying that it does.

In the example I was trying to show what the maximal cover we could achieve
for this case might look like. Obviously if there is even one authoritative
that isn't encrypting we don't need to worry about odd
secure-after-first-contact requests that go unencrypted.

The other reason to tie the signalling to DNSSEC is that it then avoids
people getting confused about the authentication being proposed here as
being an alternative to the authentication in DNSSEC. It isn't an either/or
situation. We need both sets of authentication controls.