Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation
David Conrad <drc@virtualized.org> Sat, 03 January 2015 19:17 UTC
Return-Path: <drc@virtualized.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D601A00F9 for <dnsop@ietfa.amsl.com>; Sat, 3 Jan 2015 11:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwBBevEhnW0o for <dnsop@ietfa.amsl.com>; Sat, 3 Jan 2015 11:17:17 -0800 (PST)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB391A00E6 for <dnsop@ietf.org>; Sat, 3 Jan 2015 11:17:17 -0800 (PST)
Received: by mail-pd0-f180.google.com with SMTP id fl12so9789980pdb.25 for <dnsop@ietf.org>; Sat, 03 Jan 2015 11:17:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:message-id:references:to; bh=CQvUIX+hc7juq4OadQVmyITR2/uuD5ePuDahlyzssDE=; b=Y91XeejcysJKOBH8nk8GzIw1p9pe6TJkn3awu1VhMgpIndi0eAPvmG/L/QGG6m2n8P EExNQKDMz/oN7JeqpYkN+VRWS0rq87r5vwFdqChnMcl6zgxYRaPbUGsgvZfKx/7oMa/K uMZqPs6q7qH7o0yZ7y89HVyrWzSCCYhxaClWprnVtPMu+YNwwVPTDmVDYa7jse83q+g3 k5xyC6SH0+d2ZFLf8jRRrHn0UioS2MUB6Kx7iGcn07ZOx8YxPSCg3NPmIi85qRTDfrLM VgdRujqJGxbdOr5wq3kaLqMCESgXFJGojytDuJrnPRhs76cA1r+w1aHhExxzc1T8AMMy lMTw==
X-Gm-Message-State: ALoCoQn93OK941jjVmuaP/ayJaofoXn/fQG86SYYEqscZ+7mQE1tW0i39ILP8ROAfj0x/v7pYpwX
X-Received: by 10.68.242.137 with SMTP id wq9mr77169614pbc.98.1420312636902; Sat, 03 Jan 2015 11:17:16 -0800 (PST)
Received: from [10.0.1.10] ([73.162.11.223]) by mx.google.com with ESMTPSA id xv4sm37709288pab.13.2015.01.03.11.17.15 for <dnsop@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Jan 2015 11:17:15 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0846AA3F-CB87-46B4-8561-93D57B95F9C1"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
X-Pgp-Agent: GPGMail 2.5b4
From: David Conrad <drc@virtualized.org>
In-Reply-To: <CAH1iCip7iGgM=eiaVcy3fHx+KdOJgd5Rh8zLsnDPMgoEnE-HvA@mail.gmail.com>
Date: Sat, 03 Jan 2015 11:17:13 -0800
Message-Id: <0BB798D6-60F4-492D-819A-EF4E0F5848B5@virtualized.org>
References: <CAH1iCirCRpJxHWu62nCSTCmSumXfTNHi=-jt5eWXzRgspJjm9w@mail.gmail.com> <CAH1iCip7iGgM=eiaVcy3fHx+KdOJgd5Rh8zLsnDPMgoEnE-HvA@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Nm9J-4y03Ap7zdCC6A-Xmz-Vnm4
Subject: Re: [DNSOP] Comments on draft-ietf-dnsop-qname-minimisation
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 03 Jan 2015 19:17:21 -0000
Some comments on the qname-minimisation draft: In general, while I like the idea of qname minimization, much of this draft reads like a series of complaints about bad DNS operational practices instead of providing a detailed explanation of how to minimize the query names and what that might imply. - Section 1: While the pointer to the dns-privacy draft is helpful as a reference, I figure the introduction/background section should provide an introduction to the specific problem the draft is attempting to address and why it is a problem. - Section 2: "It can be noted that minimising the amount of data sent also partially addresses the case of a wire sniffer, not just the case of privacy invasion by the servers." This probably needs a bit more explanation. If you're sniffing the wire, you'll see the final query for the full QNAME/QCLASS/QTYPE and all the intervening NS queries can simply be ignored, no? Or is the sniffer on a different wire? "Sending the full qname to the authoritative name server is a tradition, not a protocol requirment." I'd actually call it an optimization, not a tradition. - Section 3: "On the other hand, it will decrease their legal responsability, in many cases." I'm not sure it's worth raising this as "legal responsibility" in an engineering document sounds like a 'rathole of unusual size' to me. 'As an example of today, look at www.ratp.fr (not ratp.fr), which is delegated to two name servers that reply properly to "A www.ratp.fr" queries but send REFUSED to queries "NS www.ratp.fr".' I suspect this particular brokenness will be fixed at some point in the future, thus I doubt this example will be useful. 'Another way to deal with such broken name servers would be to try with A requests (A being choosen because it is the most common and hence the least revealing qtype).' I'm unclear as to how the QTYPE being requested provides significantly more information leakage -- isn't the real information leakage the actual QNAME? 'For such a name, a cold resolver will, depending how qname minimisation is implemented, send more queries.' It might be useful to go discuss ways in which qnames can be implemented. - Section 4: Might rename this section to "Performance Implication" and, in addition to discussing the negative caching stuff, provide some examples of the increase in round trips necessary to deal with probing to find zone cuts. Hope this helps. Regards, -drc
- [DNSOP] Fwd: Comments on draft-ietf-dnsop-qname-m… Brian Dickson
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… David Conrad
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Stephane Bortzmeyer
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… David Conrad
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Rubens Kuhl
- [DNSOP] "Optimization" in draft-ietf-dnsop-qname-… Paul Hoffman
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Bob Harold
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Tony Finch
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Rubens Kuhl
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Paul Vixie
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Jelte Jansen
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Tony Finch
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Paul Vixie
- Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-qna… Shumon Huque
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Warren Kumari
- Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-qna… Warren Kumari
- Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-qna… Shumon Huque
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Olafur Gudmundsson
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Rubens Kuhl
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Niall O'Reilly
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Mark Andrews
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Niall O'Reilly
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Paul Vixie
- [DNSOP] Hostname (was: Comments on draft-ietf-dns… Niall O'Reilly
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Stephane Bortzmeyer
- Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qn… Stephane Bortzmeyer
- Re: [DNSOP] Fwd: Comments on draft-ietf-dnsop-qna… Stephane Bortzmeyer
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Mark Andrews
- Re: [DNSOP] Comments on draft-ietf-dnsop-qname-mi… Niall O'Reilly