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
da...@sudo.sh
D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
