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