IETF Logo Mail Archive

Re: increasing DNS message entropy, a solution for NATs

Duane <duane@e164.org> Tue, 22 July 2008 02:21 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1143A68A6; Mon, 21 Jul 2008 19:21:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.094
X-Spam-Level:
X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 C1ZtTq9x0xCg; Mon, 21 Jul 2008 19:21:20 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14EE23A65A6; Mon, 21 Jul 2008 19:21:20 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1KL7OD-0005Qn-G5 for namedroppers-data@psg.com; Tue, 22 Jul 2008 02:14:09 +0000
Received: from [208.82.100.153] (helo=mail.aus-biz.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <duane@e164.org>) id 1KL7O9-0005QF-EX for namedroppers@ops.ietf.org; Tue, 22 Jul 2008 02:14:07 +0000
Received: from [192.168.100.244] (dsl-48-19.qld1.net.au [125.168.48.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.aus-biz.com (Postfix) with ESMTPSA id 20B5CFF26F; Tue, 22 Jul 2008 12:14:02 +1000 (EST)
Message-ID: <48854197.70704@e164.org>
Date: Tue, 22 Jul 2008 12:10:31 +1000
From: Duane <duane@e164.org>
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
MIME-Version: 1.0
To: Paul Vixie <paul@vix.com>, namedroppers@ops.ietf.org
Subject: Re: increasing DNS message entropy, a solution for NATs
References: <OF6B63EC19.5E0A6D58-ON8025748D.003A54A9-C125748D.003E1133@nominet.org.uk> <82371.1216658891@nsa.vix.com>
In-Reply-To: <82371.1216658891@nsa.vix.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

Paul Vixie wrote:

> i really don't agree that this is a solution or an alternative.  we can all
> contemplate duplicating the upstream query whenever there is a mismatch in
> only the QID or only the UDP port or only the 0x20 bits or only the Q-tuple,
> but in that case one is likely better off just retrying with TCP.  note that
> mismatches in only the UDP port are usually not application-visible, so it
> would be very hard to implement that portably on most operating systems.

This is where SSLv2 failed, they used ICMP to pass messages about
connection closure, SSLv3 onwards ignore the ICMP messages for the most
part.

-- 

Best regards,
 Duane

--
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/>

v2.36.0 | Report a Bug | By Email | System Status