Unbound DNS on IPV6
RayG
rgsub1 at btinternet.com
Wed Aug 15 12:32:20 UTC 2018
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:
=====
# For DNS Rebinding prevention
#
# All these addresses are either private or should not be routable in the
global IPv4 or IPv6 internet.
#
# IPv4 Addresses
#
private-address: 0.0.0.0/8 # Broadcast address
private-address: 10.0.0.0/8
private-address: 100.64.0.0/10
private-address: 127.0.0.0/8 # Loopback Localhost
private-address: 172.16.0.0/12
private-address: 192.0.0.0/24 # IANA IPv4 special purpose net
private-address: 192.0.2.0/24 # Documentation network TEST-NET
private-address: 192.168.0.0/16
private-address: 192.254.0.0/16
private-address: 198.18.0.0/15 # Used for testing inter-network
communications
private-address: 198.51.100.0/24 # Documentation network TEST-NET-2
private-address: 203.0.113.0/24 # Documentation network TEST-NET-3
private-address: 233.252.0.0/24 # Documentation network MCAST-TEST-NET
#
# IPv6 Addresses
#
private-address: ::1/128 # Loopback Localhost
private-address: 2001:db8::/32 # Documentation network IPv6
private-address: fc00::/8 # Unique local address (ULA) part of
"fc00::/7", not defined yet
private-address: fd00::/8 # Unique local address (ULA) part of
"fc00::/7", "/48" prefix group
private-address: fe80::/10 # Link-local address (LLA)
=====
But the above does not mention ::ffff:0:0/96
And as mentioned earlier:
https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-address-types/ipv6-addres
s-types
provides further information.
Looking at just the IPV4 addresses above then I have the following solution
which also satisfies (perhaps incorrectly) the program I am using to test my
setup.
So to protect the 'private' addresses in the ::ffff:x.x.x.x format you have
to specify them individually in the following form:
private-address: ::ffff:0.0.0.0/104 # IPV4 /8
private-address: ::ffff:10.0.0.0/104 # IPV4 /8
private-address: ::ffff:100.64.0.0/106 # IPV4 /10
private-address: ::ffff:127.0.0.0/104 # IPV4 /8
private-address: ::ffff:169.256.0.0/112 # IPV4 /16
private-address: ::ffff:172.16.0.0/108 # IPV4 /12
private-address: ::ffff:192.168.0.0/112 # IPV4 /16
private-address: ::ffff:192.254.0.0/112 # IPV4 /16
private-address: ::ffff:198.18.0.0/111 # Used for
testing inter-network communications IPV4 /15
private-address: ::ffff:198.51.100.0/120 #
Documentation network TEST-NET-2 IPV4 /24
private-address: ::ffff:203.0.113.0/120 #
Documentation network TEST-NET-3 IPV4 /24
private-address: ::ffff:233.252.0.0/120 #
Documentation network MCAST-TEST-NET IPV4 /24
I worked out in the end that you add the /n from x.x.x.x/n to 96 and that
gives the /n for the ::ffff:x.x.x.x/n At least now when I have this
configured everything seems to work as I would expect with the test program.
(but is it correct? See below)
So now the question is should any IPV4 addresses in the format of
::ffff:x.x.x.x ever be seen on the internet? Should they all be sanitized
and discarded by the unbound DNS server. If the answer to that is yes I can
confidently say that using the ::ffff:0:0/96 will definitely suffice and do
the job and my little test program needs to be updated to work in a
different way. I will pass this on to the person concerned.
Thanks to all who have helped me understand IPV6 a lot better than I did. I
still don't understand (yet) IPV6 addressing in full but I am getting there.
Regards
Ray
-----Original Message-----
From: RayG <rgsub1 at btinternet.com>
Sent: 13 August 2018 17:49
To: unbound-users at unbound.net
Subject: RE: Unbound DNS on IPV6
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
-----Original Message-----
From: Wouter Wijngaards <wouter at nlnetlabs.nl>
Sent: 13 August 2018 09:18
To: unbound-users at unbound.net
Subject: Re: Unbound DNS on IPV6
Hi RayG,
On 08/11/2018 05:38 PM, RayG via Unbound-users wrote:
> 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
>
>
>
> 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.ar
> pa. 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 <http://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:
>
> - adobe-dns-03.adobe.com
>
> 193.104.215.45
>
> adobe.com
>
> - adobe-dns-01.adobe.com
>
> 192.150.11.56
>
> adobe.com
>
> - adobe-dns-04.adobe.com
>
> 192.147.130.168
>
> adobe.com
>
> - adobe-dns-05.adobe.com
>
> 103.43.113.56
>
> adobe.com
>
> - a10-64.akam.net
>
> 96.7.50.64
>
> adobe.com
>
> - a28-67.akam.net
>
> 95.100.173.67
>
> adobe.com
>
> - a26-66.akam.net
>
> 23.74.25.66
>
> adobe.com
>
> - a7-64.akam.net
>
> 23.61.199.64
>
> adobe.com
>
> - a1-217.akam.net
>
> 193.108.91.217
>
> 2600:1401:2::d9
>
> adobe.com
>
> - a13-65.akam.net
>
> 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
>
>
>
>
>
>
>
>
>
More information about the Unbound-users
mailing list