[106695] in North American Network Operators' Group
Re: maybe a dumb idea on how to fix the dns problems i don't know....
daemon@ATHENA.MIT.EDU (Paul Vixie)
Sun Aug 10 11:56:39 2008
From: Paul Vixie <vixie@isc.org>
To: Joe Abley <jabley@ca.afilias.info>
In-Reply-To: Your message of "Sun\, 10 Aug 2008 11\:23\:19 -0400."
<CE0027BC-AB31-434A-A8AE-C0672711B5D9@ca.afilias.info>
Date: Sun, 10 Aug 2008 15:56:23 +0000
X-Vix-MailScanner-From: vixie@vix.com
Cc: nanog@merit.edu
Errors-To: nanog-bounces@nanog.org
--=-=-=
(here we are discussing dns protocol details on nanog@ again. must be sunday.)
> From: Joe Abley <jabley@ca.afilias.info>
>
> It may be worth clarifying that "not considering TCP mandatory" above is
> an implementation/operational choice, and not something that seems to be
> clearly endorsed by RFC 1035, such as it is.
>
> There are a lot of people who insist that TCP transport is used for
> nothing other than zone transfers in the DNS, and they do so not out of
> concern over potential TCP state explosion on their servers but instead
> because "that's what the last guy told me". That kind of reasoning
> doesn't need a bigger posse.
>
> Joe
>
> 4.2. Transport
> ...
actually, it does (need a bigger posse). a little further on in RFC 1035 we
find this gem:
+---
| 4.2.2. TCP usage
| ...
| Several connection management policies are recommended:
|
| - The server should not block other activities waiting for TCP
| data.
|
| - The server should support multiple connections.
|
| - The server should assume that the client will initiate
| connection closing, and should delay closing its end of the
| connection until all outstanding client requests have been
| satisfied.
|
| - If the server needs to close a dormant connection to reclaim
| resources, it should wait until the connection has been idle
| for a period on the order of two minutes. In particular, the
| server should allow the SOA and AXFR request sequence (which
| begins a refresh operation) to be made on a single connection.
| Since the server would be unable to answer queries anyway, a
| unilateral close or reset may be used instead of a graceful
| close.
+---
in the era of RFC 1035 the philosophy was "be liberal in what you accept and
be conservative in what you generate" because the other people on the network
weren't trying to spam, ddos, or poison you. the above text is effectively a
"please ddos me" bumper sticker worn across the ass of anyone who implements
it.
we're having a terrible time with UDP now simply because upstream sockets can
now only be used once before they're closed, and any long-running query can
tie up a file descriptor for a longish enough time to drain the pool down to
the point where new downstream queries can't be accepted because existing
upstream queries have not completed. file descriptors are the new "carbon
footprint" of DNS. but at least in the UDP case the shortage is experienced
only by the initiator. in the TCP case the shortage is experienced by both
the initiator and the responder, and the responder is shackled by [4.2.2].
i don't want to completely dismiss the underlying idea of "fall back to TCP
if someone guesses a few QID's wrong". however, i dismiss the idea that it's
a simple universal solution. on a mailing list called namedroppers@ where i
would more likely expect to see a discussion of fine points of DNS protocol,
i spake thusly about a week ago, and so far have heard no reply, though i've
implemented these recommendations on a server that only keeps 64 descriptors
open at a time and it's been incredibly resistant to my poisoning attempts.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--=-=-=
Content-Type: message/rfc822
Content-Disposition: attachment; filename=4629
Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: vixie@vix.com
Delivered-To: vixie@nsa.vix.com
Received: from mx.isc.org (mx.isc.org [IPv6:2001:4f8:0:2::1c])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mx.isc.org", Issuer "ISC CA" (not verified))
by nsa.vix.com (Postfix) with ESMTPS id 339E6A9CB1
for <vixie@vix.com>; Wed, 30 Jul 2008 19:10:31 +0000 (UTC)
(envelope-from owner-namedroppers@ops.ietf.org)
Received: from psg.com (psg.com [IPv6:2001:418:1::62])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "psg.com", Issuer "RGnet Root CA" (not verified))
by mx.isc.org (Postfix) with ESMTPS id 1066811401E;
Wed, 30 Jul 2008 19:10:28 +0000 (UTC)
(envelope-from owner-namedroppers@ops.ietf.org)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD))
(envelope-from <owner-namedroppers@ops.ietf.org>) id 1KOGuN-0008P8-2Z
for namedroppers-data@psg.com; Wed, 30 Jul 2008 19:00:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mx.isc.org
X-Spam-Level:
X-Spam-Status: No, score=-10.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,
USER_IN_WHITELIST_TO autolearn=ham version=3.2.4, No
Received: from [2001:4f8:3:bb:230:48ff:fe5a:2f38] (helo=nsa.vix.com)
by psg.com with esmtps (TLSv1:CAMELLIA256-SHA:256)
(Exim 4.69 (FreeBSD)) (envelope-from <vixie@vix.com>)
id 1KOGuJ-0008OR-7c
for namedroppers@ops.ietf.org; Wed, 30 Jul 2008 19:00:21 +0000
Received: from nsa.vix.com (localhost [127.0.0.1])
by nsa.vix.com (Postfix) with ESMTP id 84708A9D1B;
Wed, 30 Jul 2008 19:00:06 +0000 (UTC)
(envelope-from vixie@nsa.vix.com)
From: Paul Vixie <vixie@isc.org>
To: Jelte Jansen <jelte@NLnetLabs.nl>
cc: namedroppers@ops.ietf.org
In-Reply-To: Your message of "Wed, 30 Jul 2008 20:09:13 +0200."
<4890AE49.7040006@NLnetLabs.nl>
References: <200807281555.m6SFsxAO021711@stora.ogud.com>
<027b01c8f17e$f99b0a80$ecd11f80$@com>
<1135.1217352731@nsa.vix.com> <4890AE49.7040006@NLnetLabs.nl>
X-Mailer: MH-E 8.0.3; nil; GNU Emacs 22.2.1
Date: Wed, 30 Jul 2008 19:00:06 +0000
Message-ID: <71458.1217444406@nsa.vix.com>
MIME-Version: 1.0
X-Vix-MailScanner: Found to be clean, Found to be clean
Subject: Re: XQID (Re: Forgery Resistance phase #2 )
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
X-Vix-MailScanner-Information: Please contact the ISP for more information
X-MailScanner-ID: 339E6A9CB1.78AB1
X-Vix-MailScanner-From: owner-namedroppers@ops.ietf.org
> correct me if i'm wrong, but i think you might be confusing two
> proposals here. XQID and the EDNS PING proposal. XQID appends entropy to
> the actual query name, and shouldn't be downgradeable by leaving out
> something (because then the answer wouldn't be the same as the query).
>
> Using EDNS PING is 'cleaner' (it doesn't muck with the query), but would
> need something like you ask for here.
yes, and i apologize for my confusion, i'm jittery from too much coffee and
too little sleep in the last few weeks. PING with that modification to
EDNS's fallback would work, though i'm beginning to realize that the
requirement should be phrased as "each query transaction must be protected
by XYZ bits of high quality random entropy, which can be reached using any
combination of udp port number, query ID, DNS 0x20 bits, PING, or repeated
queries". XYZ is probably about 50 if we want to rule out guessing
attacks.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
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/>
--=-=-=--
