Subject: [DNSOP] available, a test domain for EDNS client subnet

From: bert hubert <[email-masked]>
Date: Wed, 11 Nov 2015 17:48:37 +0100

Hi everybody,

With help from PowerDNS ueber value community member Aki Tuomi, the GeoIP
backend in PowerDNS has been extended to use the netmask information
contained in the Maxmind geolocation database.

We needed this because we couldn't find a lot of domains out there that
actually respond with differing scope lengths to EDNS client subnet queries.

And we needed testing domains because we're nearly done adding EDNS client
subnet to PowerDNS Recursor 4.0 (authoritative has had it for years).

To test, try:

$ dig -t txt www.geo.powerdns.com 
www.geo.powerdns.com.	30	IN	TXT	"hallo Nederland 86.82.68.237/12"

And for IPv6:
www.geo.powerdns.com.   29      IN      TXT     "hallo Nederland 2001:888:2000:1d::/30"

It will send back information that differs per continent, and it knows about
some countries specifically (like The Netherlands), but not others:

www.geo.powerdns.com.	IN	CNAME	30 jpn.as.service.geo.powerdns.com.
jpn.as.service.geo.powerdns.com.	IN	TXT	30 "hello asia 106.177.158.0/13 jpn"

The YAML behind this service can be found on http://pastebin.com/zbpznMa2

We'll keep this service running for now, but it might drop out from time to
time. But for now, if you need to test, www.geo.powerdns.com TXT is there
for you.

	Bert

---

From: dagon <[email-masked]>
Date: Wed, 11 Nov 2015 15:08:55 -0500

> 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
[email-masked]
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717