Re: [DNSOP] Priming query transport selection

Olafur Gudmundsson <ogud@ogud.com> Wed, 13 January 2010 21:57 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C99D3A680C for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 13:57:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.68
X-Spam-Level:
X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnWf4vn+s5cF for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 13:57:50 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 144233A679C for <dnsop@ietf.org>; Wed, 13 Jan 2010 13:57:49 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DM2GAH070364; Wed, 13 Jan 2010 17:02:16 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001132202.o0DM2GAH070364@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 13 Jan 2010 16:57:43 -0500
To: Edward Lewis <Ed.Lewis@neustar.biz>, dnsop@ietf.org
From: Olafur Gudmundsson <ogud@ogud.com>
In-Reply-To: <a06240801c773e8e88485@[10.31.201.49]>
References: <201001131823.o0DINxYv068180@stora.ogud.com> <a06240801c773e8e88485@[10.31.201.49]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on 66.92.146.20
Cc: ed.lewis@neustar.biz
Subject: Re: [DNSOP] Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2010 21:57:51 -0000

At 16:33 13/01/2010, Edward Lewis wrote:
>At 13:19 -0500 1/13/10, Olafur Gudmundsson wrote:
>
>>The benefit is that a single query can retrieve the signed root NS set
>>and all the signed glue records.
>
>I am not certain that the cost of doing TCP for this is worth the 
>benefit of getting a signed priming response.  I agree with section 
>2.4 - no DO bit.
>
>What does a DNSSEC-protected priming query gain you?
>
>Accepting any old priming query and having a root SEP configured, if 
>the query is right all things work.  If the query is wrong/forged 
>you won't get anywhere any how.  (Without going into the weeds here 
>- what if one IP address were forged, what if it were 6, 16, or all of them?)
>
>(13 name servers => 13 A records + 7 AAAA records last check)
>
>Besides the warm and fuzzy feeling, what do you gain? (Keep in mind 
>all of the TCP traffic it would take to get warm and fuzzy.)

Well having TCP used for all priming queries would make me feel better
as TCP traffic is harder to forge.

But seriously DNSSEC signed and validated data should protect the
the resolver from going to the forged addresses.
Yes someone can forge the answer and DoS the resolver into believing that
nothing works.
The situation is "." and root-servers.net. zones are hosted on the
root servers, thus the same servers will get all follow-up questions
about signed address sets as the priming query.
Resolvers like to ask the "close" servers for information thus it
is almost certain that over time the resolver will send a question
to all root servers.

Based on this I think one TCP connection is better than 14-27
UDP ones. (Resolver that only supports one transport should never
ask for the address records it will not use).
We can even take this one step further and ask both priming questions
over the same TCP connection that is NS and DNSKEY.

Ed in my mind this is straight forward engineering question,
which approach is better as in cheaper/faster/safer.


>At 16:05 -0500 1/13/10, Olafur Gudmundsson wrote:
>
>>Why not ask for signatures ?
>
>Same reason it is no longer fashionable to include keys in signed 
>responses - signatures are a big load.  Yes, you'll know sooner if a 
>server's IP address is a problem, but you'd figure it out before it 
>mattered anyway (if you ever use that server).
>--

This is totally different.
Adding DNSKEY to "random" answers was an "optimization" in trading
off answer size vs delay in first verification for a zone.
The choice made by early RFC's and implementations was the wrong
one for the Internet we have today, where UDP fragments have high
chance of not getting through.

         Olafur