Maintained by: NLnet Labs

[Unbound-users] ends client subnet testing

DeJong, Steve
Wed May 6 19:13:10 CEST 2015


Hello,

I have been testing the edns-client-subnet support branch with the latest sync (thanks for the recent trunk sync) and there appears to be an issue when the subnet enabled query results in a CNAME response pointing to an A record that does not have client subnet information with it.

In my current setup I am running:
version: 1.5.4
verbosity: 3
threads: 2
modules: 3 [ subnet validator iterator ]
uptime: 1471 seconds
options: control(ssl)
unbound (pid 3307) is running...

My unbound.conf contains:
        send-client-subnet: 156.154.64.0/24
        send-client-subnet: 156.154.65.0/24
        send-client-subnet: 156.154.66.0/24
        send-client-subnet: 156.154.67.0/24
        send-client-subnet: 156.154.68.0/24
        send-client-subnet: 156.154.69.0/24
        send-client-subnet: 2001:0502:F3FF::0000/48
        send-client-subnet: 2610:00A1:1014::0000/48
        send-client-subnet: 2610:00A1:1015::0000/48
        send-client-subnet: 2610:00A1:1016::0000/48
        send-client-subnet: 2610:00A1:1017::0000/48
        send-client-subnet: 2001:0502:4612::0000/48

        client-subnet-opcode: 8
        max-client-subnet-ipv6: 48
        max-client-subnet-ipv4: 24


When performing a dig against a hostname that returns a CNAME I see that the scope netmask is set to 0:
; <<>> DiG 9.10.1-P1 <<>> @127.0.0.1 +subnet=4.34.119.15 whereami.ultradns.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6362
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 4.34.119.0/24/0
;; QUESTION SECTION:
;whereami.ultradns.net. IN A

;; ANSWER SECTION:
whereami.ultradns.net. 60 IN CNAME US-NY-New-York.ipi.ultrasupport.net.
US-NY-New-York.ipi.ultrasupport.net. 3600 IN A 127.0.0.2

;; AUTHORITY SECTION:
ipi.ultrasupport.net. 3600 IN NS pdns196.ultradns.co.uk.
ipi.ultrasupport.net. 3600 IN NS pdns196.ultradns.com.
ipi.ultrasupport.net. 3600 IN NS pdns196.ultradns.net.
ipi.ultrasupport.net. 3600 IN NS pdns196.ultradns.biz.
ipi.ultrasupport.net. 3600 IN NS pdns196.ultradns.org.
ipi.ultrasupport.net. 3600 IN NS pdns196.ultradns.info.

;; Query time: 1121 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 06 13:47:55 UTC 2015
;; MSG SIZE  rcvd: 318

Some pcap analysis – attached – shows that the query for the CNAME responds with the correct scope netmask of 24. Unbound then goes to chase the CNAME and gets an A record response that does not contain client subnet information and the final response to the client sets the scope netmask to 0 which is what is shown in the dig result above. This response is optimized for the subnet that was sent but since the end scope netmask has been set to 0 all subsequent lookups, possibly from other clients, will get a cached answer that may not be optimal for that client. For example the next dig from a different subnet (Amsterdam) is answered from cache with an answer that is sub-optimal. This behavior is identical when the cname points to an address in zone as well.

; <<>> DiG 9.10.1-P1 <<>> @127.0.0.1 +subnet=212.72.53.207 whereami.ultradns.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33629
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 212.72.53.207/32/0
;; QUESTION SECTION:
;whereami.ultradns.net. IN A

;; ANSWER SECTION:
whereami.ultradns.net. 46 IN CNAME US-NY-New-York.ipi.ultrasupport.net.
US-NY-New-York.ipi.ultrasupport.net. 3586 IN A 127.0.0.2

;; AUTHORITY SECTION:
ipi.ultrasupport.net. 3586 IN NS pdns196.ultradns.co.uk.
ipi.ultrasupport.net. 3586 IN NS pdns196.ultradns.com.
ipi.ultrasupport.net. 3586 IN NS pdns196.ultradns.net.
ipi.ultrasupport.net. 3586 IN NS pdns196.ultradns.biz.
ipi.ultrasupport.net. 3586 IN NS pdns196.ultradns.org.
ipi.ultrasupport.net. 3586 IN NS pdns196.ultradns.info.

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed May 06 16:43:10 UTC 2015
;; MSG SIZE  rcvd: 319

The draft, as far as I can tell , doesn’t say anything about chasing the CNAME so is this the expected behavior for Unbound? It would seem that the final response should use the client subnet information from the original CNAME response.

On the other hand all of the tests where the response is a plain A or AAAA record appear to be working well.

Thanks
Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20150506/a482d2f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ednssubnet.pcap
Type: application/octet-stream
Size: 58963 bytes
Desc: ednssubnet.pcap
URL: <https://unbound.nlnetlabs.nl/pipermail/unbound-users/attachments/20150506/a482d2f1/attachment-0001.obj>