Re: [DNSOP] available, a test domain for EDNS client subnet
dagon <dagon@sudo.sh> Wed, 11 November 2015 20:08 UTC
Return-Path: <dagon@sudo.sh>
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 E4DF01A000B for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2015 12:08:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.046
X-Spam-Level:
X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_IS_SMALL6=0.556, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 WVoDaJPQnc9X for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2015 12:08:57 -0800 (PST)
Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4A55A1A0006 for <dnsop@ietf.org>; Wed, 11 Nov 2015 12:08:56 -0800 (PST)
Received: by sudo.sh (Postfix, from userid 1000) id D10F8343FDE; Wed, 11 Nov 2015 15:08:55 -0500 (EST)
Date: Wed, 11 Nov 2015 15:08:55 -0500
From: dagon <dagon@sudo.sh>
To: bert hubert <bert.hubert@netherlabs.nl>
Message-ID: <20151111200855.GB8313@sudo.sh>
References: <20151111164836.GE29064@xs.powerdns.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20151111164836.GE29064@xs.powerdns.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/jfVScq7O6WTD-Tn6IlMNSnoqWJo>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] available, a test domain for EDNS client subnet
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: <https://mailarchive.ietf.org/arch/browse/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, 11 Nov 2015 20:08:59 -0000
On Wed, Nov 11, 2015 at 05:48:37PM +0100, bert hubert wrote: > To test, try: > > $ dig -t txt www.geo.powerdns.com > www.geo.powerdns.com. 30 IN TXT "hallo Nederland 86.82.68.237/12" This is very useful. I also created an authority zone for testing EDNS client subnet properties, but it additionally includes the parsed EDNS payload as well as recursive IP properties: dig +short -t txt edns-client-sub.net The country code information is drawn from maxmind as well. If there's edns payload for client subnet information, this is included, e.g.: dig @8.8.8.8 +short -t txt edns-client-sub.net "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'US',\ 'ip':'128.61.26.0','mask':'24','scope':'0'},'ecs':'True', 'ts':'1447266546.81','recursive':{'cc':'DE','srcip':'74.125.42.48',\ 'sport':'39827'}}" The output is json, which all the kids use these days. This domain might be useful for testing. * * * May I say a few words about EDNS client subnet implementation choices? Using this domain, I think one can detect an issue with Google's 8.8.8.8 recursive---or at least a surprising behavior that I'd argue is deficient, which I hope PowerDNS Recursive 4.x might avoid. It seems that if one crafts a stub query, specifying a mask >/24, the Google recursive nonetheless forwards the client's full /24 address information information to the authority. This is demonstrated below, in case I've misunderstood something. First, here's a convenience script for displaying the json output with the useful 'jq' tool: $ cat bin/txt2jq #!/bin/bash while read line do echo $line | tr -d '"' | tr "'" '"' done < "${1:-/dev/stdin}" | jq . Next, I'll note that the draft specification describes what DNS speakers should do with masked queries: "In replies, it mirrors the same value as in the requests". The draft also says that a mask of /0 is a form of client opt-out (even though there are no client tools that generate this yet). The /0 scoped opt-out works, but all other stub queries are sent as a /24, regardless of the stub's chosen mask size. Using a very handy patch from Wilmer van der Gaast to include EDNS client subnet options in dig command (compiled into an 'ecs_dig' binary), one can craft test queries: $ ecs_dig @8.8.8.8 +short -t txt \ +client=0.0.0.0/0 edns-client-sub.net | txt2jq { "ecs": "False", "ts": "1446623086.68", "recursive": { "cc": "DE", "srcip": "74.125.42.51", "sport": "34557" } } So this confirms that a /0 stub query opts-out successfully. But when setting another mask, including one larger than a /24, the server at 8.8.8.8 sends the /24 information to the authority. Here, I try to reveal only my /16 (i.e., I want the benefits of geolocalized recursion, but I also want some measure of privacy): $ ecs_dig @8.8.8.8 +short -t txt \ +client=143.215.0.0/16 edns-client-sub.net | txt2jq { "ecs_payload": { "family": "1", "optcode": "0x08", "cc": "US", "ip": "143.215.142.0", "mask": "24", "scope": "0" }, "ecs": "True", "ts": "1446623207.56", "recursive": { "cc": "DE", "srcip": "74.125.42.51", "sport": "62060" } } I'll be sure to test PowerDNS Recursor 4.x for this behavior, to see how it compares to Google's implementation. (I'm still using the 3.x pdns stable branches, which only has authority support for ECS, I believe.) I'd argue that stubs should have the same ability to specify a mask, just as authorities can specify preferred masks in answer. I'd also argue that the clients' mask size should take precedence over any stated mask preferred by the authority, at least with respect to the iterative messages. (Caching scope, of course, is up to the authority.) The specification is a draft, and there remains room for implementation-specific interpretations. So perhaps this is not a bug, exactly. But I'd argue that this behavior surprises the stub, who otherwise followed the specification, hoping to preserve some privacy, while not entirely opting out of EDNS client subnet messaging. It's nice that powerdns now has this recursive capability. Based on the pdns roadmap 4.0 (see http://mailman.powerdns.com/pipermail/pdns-users/2015-June/011516.html ), should I wait for pdns 4.1 or later to test this and related EDNS client subnet behaviors? -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717