Unbound DNS on IPV6

Unbound
1

Hi,

First apologies for the length of the post.

Following on from my experiments with UDP/TCP I have been trying to verify that the private addresses for IPV6 I have set up were working as expected.

private-address: ::/128 # Unspecified address

private-address: ::1/128 # Loopback Localhost

private-address: 2001:db8::/32 # Documentation network IPv6

private-address: 2001:10::/28 # Overlay Routable Cryptographic Hash IDentifiers (ORCHID) addresses

private-address: fc00::/7 # Unique local address (ULA) part of “fc00::/7”, not defined yet

private-address: fe80::/10 # Link-local address (LLA)

? private-address: ::ffff:0:0/96

? private-address: ::ffff/96

? = not sure which is correct.

From this page I gleaned (and I hope I have this correct):

https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-address-types/ipv6-address-types

That the addresses above should never appear on the internet and as such are “private” and setting them in the config file as above should ensure that DNS rebinding attacks cannot happen on IPV6. At least that is what I think this is all about.

(

For IPV4, I am happy that I have these correctly configured and my checks bear this out.

private-address: 127.0.0.0/8 # Loopback Localhost

private-address: 10.0.0.0/8

private-address: 172.16.0.0/12

private-address: 192.168.0.0/16

private-address: 169.254.0.0/16

)

As you may have gathered I am not really an expert in the set up so I try to verify what I am doing from what I can glean from commands I can use, the internet and helpful people like yourselves.

To this end I thought OK lets turn off unbound’s IPV4 capability (My router and network support IPV6) but as you can see below by pinging the root servers. However when I try to do a lookup unbound gives me a SRVFAIL

C:>nslookup www.adobe.com

Server: localhost

Address: ::1

*** localhost can’t find www.adobe.com: Server failed

C:>dig www.adobe.com

; <<>> DiG 9.12.2-P1 <<>> www.adobe.com

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24704

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.adobe.com. IN A

;; Query time: 1187 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Sat Aug 11 16:04:02 GMT Summer Time 2018

;; MSG SIZE rcvd: 42

C:>ping 2001:503:d414::30

Pinging 2001:503:d414::30 with 32 bytes of data:

Reply from 2001:503:d414::30: time=152ms

Reply from 2001:503:d414::30: time=152ms

Reply from 2001:503:d414::30: time=152ms

Reply from 2001:503:d414::30: time=151ms

Ping statistics for 2001:503:d414::30:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 151ms, Maximum = 152ms, Average = 151ms

The address above is one of the root servers: f.gtld-servers.net.

C:>dig -x 2001:503:d414::30

; <<>> DiG 9.12.2-P1 <<>> -x 2001:503:d414::30

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2502

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.1.4.d.3.0.5.0.1.0.0.2.ip6.arpa. IN PTR

;; ANSWER SECTION:

0.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.1.4.d.3.0.5.0.1.0.0.2.ip6.arpa. 86303 IN PTR f.gtld-servers.net.

;; AUTHORITY SECTION:

4.1.4.d.3.0.5.0.1.0.0.2.ip6.arpa. 86301 IN NS a3.verisigndns.com.

4.1.4.d.3.0.5.0.1.0.0.2.ip6.arpa. 86301 IN NS a2.verisigndns.com.

4.1.4.d.3.0.5.0.1.0.0.2.ip6.arpa. 86301 IN NS a1.verisigndns.com.

;; Query time: 15 msec

;; SERVER: ::1#53(::1)

;; WHEN: Sat Aug 11 16:08:28 GMT Summer Time 2018

;; MSG SIZE rcvd: 199

Doing a lookup using my routers DNS server you can see works (but that is using IPV4) but the info returned shows that the ping works. IPV6 is alive and kicking.

C:>nslookup www.microsoft.com 192.168.10.1

Server: Router

Address: 192.168.10.1

Non-authoritative answer:

Name: e13678.dspb.akamaiedge.net

Addresses: 2a02:26f0:13b:38b::356e

2a02:26f0:13b:38f::356e

84.53.169.145

Aliases: www.microsoft.com

www.microsoft.com-c-3.edgekey.net

www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net

So we can see www.microsoft.com is pingable via IPV6

C:>ping 2a02:26f0:13b:38f::356e

Pinging 2a02:26f0:13b:38f::356e with 32 bytes of data:

Reply from 2a02:26f0:13b:38f::356e: time=9ms

Reply from 2a02:26f0:13b:38f::356e: time=9ms

Reply from 2a02:26f0:13b:38f::356e: time=10ms

Reply from 2a02:26f0:13b:38f::356e: time=9ms

Ping statistics for 2a02:26f0:13b:38f::356e:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 9ms, Maximum = 10ms, Average = 9ms

Then I thought lets try this to ty and prove IPV6 can do DNS resolution

C:>dig @f.gtld-servers.net. -6 www.microsoft.com

; <<>> DiG 9.12.2-P1 <<>> @f.gtld-servers.net. -6 www.microsoft.com

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9354

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 9

;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.microsoft.com. IN A

;; AUTHORITY SECTION:

microsoft.com. 172800 IN NS ns3.msft.net.

microsoft.com. 172800 IN NS ns1.msft.net.

microsoft.com. 172800 IN NS ns2.msft.net.

microsoft.com. 172800 IN NS ns4.msft.net.

;; ADDITIONAL SECTION:

ns3.msft.net. 172800 IN A 193.221.113.53

ns3.msft.net. 172800 IN AAAA 2620:0:34::53

ns1.msft.net. 172800 IN A 208.84.0.53

ns1.msft.net. 172800 IN AAAA 2620:0:30::53

ns2.msft.net. 172800 IN A 208.84.2.53

ns2.msft.net. 172800 IN AAAA 2620:0:32::53

ns4.msft.net. 172800 IN A 208.76.45.53

ns4.msft.net. 172800 IN AAAA 2620:0:37::53

;; Query time: 156 msec

;; SERVER: 2001:503:d414::30#53(2001:503:d414::30)

;; WHEN: Sat Aug 11 15:45:47 GMT Summer Time 2018

;; MSG SIZE rcvd: 302

C:>

Also this seems to work OK:

C:>nslookup

Default Server: localhost

Address: ::1

server 2001:503:d414::30

Default Server: f.gtld-servers.net

Address: 2001:503:d414::30

www.adobe.com

Server: f.gtld-servers.net

Address: 2001:503:d414::30

Name: www.adobe.com

Served by:

193.104.215.45

adobe.com

192.150.11.56

adobe.com

192.147.130.168

adobe.com

103.43.113.56

adobe.com

96.7.50.64

adobe.com

95.100.173.67

adobe.com

23.74.25.66

adobe.com

23.61.199.64

adobe.com

193.108.91.217

2600:1401:2::d9

adobe.com

2.22.230.65

adobe.com

exit

So the question is am I tripping myself up somewhere along the line or is unbound not working for DNS resolution on IPV6 only?

The log file verbosity 4 is here:

https://1drv.ms/u/s!As73rPtzISrUjyCR6j9ArQPW5i5d

Regards

Ray

2

Hi RayG,

Hi,

First apologies for the length of the post.

Following on from my experiments with UDP/TCP I have been trying to
verify that the private addresses for IPV6 I have set up were working as
expected.

I'll try to put some answers here.

From your logs it looks like unbound has two problems: some sites do not
have an IPv6 capable nameserver in their lookup path, and this causes
unbound to servfail, because there are no IPv6 enabled servers that it
can query to answer your question. www.microsoft.com is one of them
(somewhere in the CDN (akadns) it seems to have only A records). The
other problem, from the long lookup lists, is that you have
harden-referral-path which creates deeper lookups to check things, and
this with IPv6 only causes more recursion. Deeper than the default
configuration allows, and unbound prunes that deep recursion and creates
more SERVFAIL notices in the logs. This recursion depth can be fixed by
setting the target-fetch-policy: "3 2 1 0 0 0 0 0" . This adds three
more recursion depths, and works for me to resolve those SERVFAILs that
appear in the logs. But more recursion does not find an IPv6 capable
server for some of the names, and this is what causes the lookup failures.

You note question marks around some private addresses. From the page
you reference, the ::ffff:0:0/96 notation is one that unbound can parse
and use. The ::ffff/96, is likely wrong, the /96 makes unbound ignore
the lower bits, that you set to ffff, so it is like 0::0/96, and this is
not what you wanted, I think.

Best regards, Wouter

3

Hi Wouter,

You said:

"From the page you reference, the ::ffff:0:0/96 notation is one that unbound
can parse and use."

Thanks for that but when I include that address things go a little awry with
the program I am using to check things are working OK.

https://www.grc.com/dns/benchmark.htm

I am getting inconsistent results and it reports that queries are not being
answered consistently, with the ::ffff:0:0/96 address not there (commented
out) things are consistent but not as I am expecting.

Would you like to give the program a try? I am trying to get a full Green
Outer Ring to the server on 127.0.0.1 But I get differing results as you can
see from the images in the zip file:

https://1drv.ms/u/s!As73rPtzISrUjyKEXqbyJ2Kuf5KE

Image *_3 is what happened when I removed all the namservers that the
program tests and just left the local one, as you can see from the included
(verbose 4) log there are no "error:" lines (the log is with just the one
nameserver to re-characterise) but I don't understand why it thinks things
are inconsistent when that above IPV6 Private address is added, without that
the replies seem to be consistent but I only get a full Blue circle which
suggests that the private addresses for IPV6 are not effective.

BTW to see the options click on the red snowflake like icon top left of the
title bar. There are more options there than in the add/remove button. The
"Re-Verify internet connectivity" is the option that I repeat to see what
the latest configuration change has done.

The info displayed in the images is the status tab under the Nameservers tab

I hope you find the program useful

Regards
Ray

4

Hi Wouter,

Ok I have found the problem and I now understand a little more of what is
happening:

The address - ::ffff:0:0/96 covers 0.0.0.0 to 255.255.255.255 so basically
ALL ipv4 addresses in the format of ::ffff:192.168.0.0. The program I was
using DNSBench.exe tries to verify internet connectivity by using
::ffff:4.4.4.4 but that fails because ALL IPV4 addresses in this format are
sanitized (removed correctly) by unbound.

I found a source of 'Private' addresses on this link:

https://forum.opnsense.org/index.php?topic=1416.0

which has this list of addresses:

5

This is off on a tangent which isn't very relevant to your problem, but it
might still be of interest.

You might want to add to your bogon list:

169.254.0.0/16 # link-local zeroconf

I think this entry is a mistake - typo for 169.254?

private-address: 192.254.0.0/16

There's a bunch of weird stuff in 2001::/23 some of which you might want
to blacklist, e.g. 2001:2::/48 which is analogous to the IPv4 test
networks.

https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

Tony.

6

Thanks Tony

Your link led to this page which I think makes it clear that all
::ffff:x.x.x.x IPv4-mapped Address should not be seen at all on the
internet.

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-specia
l-registry.xhtml

BTW I did spot a typo after (sigh) I pushed the send button on the user list
update 169.256... should of course be 169.254...

And yes the private-address: 192.254.0.0/16 was another one - sorry

I will update the list with the proper items.

Looks like from line 7 on the above iana page shows that 2001::/23 should
perhaps be the entry as it show False across the page unless you have some
need for the addresses

So the definitive list as it stands at the moment (with typo's corrected I
hope) is:

  # IPv4 Addresses