Re: Additional filtering of responses

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Fri, 08 August 2008 06:29 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A1B3A6C93; Thu, 7 Aug 2008 23:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.196
X-Spam-Level:
X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, RDNS_NONE=0.1]
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 YjAKKpP42gxj; Thu, 7 Aug 2008 23:29:52 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A35C13A6A92; Thu, 7 Aug 2008 23:29:52 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KRLLB-000FFD-QN for namedroppers-data@psg.com; Fri, 08 Aug 2008 06:20:45 +0000
Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <mohta@necom830.hpcl.titech.ac.jp>) id 1KRLL7-000FB8-Ak for namedroppers@ops.ietf.org; Fri, 08 Aug 2008 06:20:43 +0000
Received: (qmail 8723 invoked from network); 8 Aug 2008 07:02:10 -0000
Received: from s208130.ppp.asahi-net.or.jp (HELO necom830.hpcl.titech.ac.jp) (220.157.208.130) by necom830.hpcl.titech.ac.jp with SMTP; 8 Aug 2008 07:02:10 -0000
Message-ID: <489BE3FB.8030104@necom830.hpcl.titech.ac.jp>
Date: Fri, 08 Aug 2008 15:13:15 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: ja, en
MIME-Version: 1.0
To: Wouter Wijngaards <wouter@NLnetLabs.nl>
CC: Namedroppers <namedroppers@ops.ietf.org>
Subject: Re: Additional filtering of responses
References: <489AD5E3.20708@nlnetlabs.nl>
In-Reply-To: <489AD5E3.20708@nlnetlabs.nl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

Wouter Wijngaards wrote:

> A new version of my resolver (Unbound) with additional filtering of
> responses to counter the recently disclosed vulnerability at blackhat
> was just released. This filtering is in addition to the bailiwick
> checking.

No.

If you properly handle additional glue As to be tagged by query,
glue As does not need any bailiwick checking.

As answer non-glue additional information needs exact matching with
query, the information needs no bailiwick checking.

"Bailiwick" was considered to be a valid concept for non-glue
information but is never a valid concept for glue-As.

No WG consensus can override scientific nature of the DNS referral
mechanism.

> The best solution is of course DNSSEC.

A better solution, a lot more easier to deploy than DNSSEC, is to
use TCP, deployment of which is, of course, still hard.

However, it is only as hard as updating all the install bases,
including those on various types of NAT boxed, of DNS so that
they can treat glue and other information properly.

> Crypto signatures instead of randomisation games. Enable DNSSEC
> validation now.

Because of complexity of DNSSEC caused by poor combination of DNS
and public key cryptography, there are a several subtle hacking,
which are not present in PODS (plain old DNS), performed to make
it work.

With such additional subtlities, it is practically impossible to
be sure that DNSSEC is more secure than PODS.

Remember that even PODS has a lot of unexpected security
holes.

							Masataka Ohta


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>