RE: Unbound DNS on IPV6
Thanks Tony Your link led to this page which I think makes it clear that all :::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 # 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: 169.254.0.0/16 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: 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 # #private-address: 239.0.0.0/24# GRC Version control do not enable apart from for testing. # # IPv6 Addresses # # https://tools.ietf.org/html/rfc5156 # private-address: ::/128 # Unspecified address IPV4 0.0.0.0 http://www.iana.org/go/rfc4291 private-address: ::1/128# Loopback Localhost http://www.iana.org/go/rfc4291 private-address: 2001::/23 # IETF Protocol Assignments http://www.iana.org/go/rfc2928 private-address: 2001:db8::/32 # Documentation network IPv6 http://www.iana.org/go/rfc3849 private-address: 2001:2::/48# is reserved for Benchmarking http://www.iana.org/go/rfc5180 http://www.rfc-editor.org/errata_search.php?eid=1752 private-address: fc00::/7 # 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) = 169.254.0.0/16 private-address: :::0:0/96 # IPv4-mapped Address http://www.iana.org/go/rfc4291 Any updates comments appreciated. Ray
RE: Unbound DNS on IPV6
RayG via Unbound-users wrote: 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. -- f.anthony.n.finchhttp://dotat.at/ champion the freedom, dignity, and well-being of individuals
RE: Unbound DNS on IPV6
Hi Wouter, Ok I have found the problem and I now understand a little more of what is happening: The address - :::0:0/96 covers 0.0.0.0 to 255.255.255.255 so basically ALL ipv4 addresses in the format of :::192.168.0.0. The program I was using DNSBench.exe tries to verify internet connectivity by using :::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 :::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 :::x.x.x.x format you have to specify them individually in the following form: private-address: :::0.0.0.0/104 # IPV4 /8 private-address: :::10.0.0.0/104# IPV4 /8 private-address: :::100.64.0.0/106 # IPV4 /10 private-address: :::127.0.0.0/104 # IPV4 /8 private-address: :::169.256.0.0/112 # IPV4 /16 private-address: :::172.16.0.0/108 # IPV4 /12 private-address: :::192.168.0.0/112 # IPV4 /16 private-address: :::192.254.0.0/112 # IPV4 /16 private-address: :::198.18.0.0/111 # Used for testing inter-network communications IPV4 /15 private-address: :::198.51.100.0/120# Documentation network TEST-NET-2 IPV4 /24 private-address: :::203.0.113.0/120 # Documentation network TEST-NET-3 IPV4 /24 private-address: :::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 :::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 :::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 :::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 Sent: 13 August 2018 17:49 To: unbound-users@unbound.net Subject: RE: Unbound DNS on IPV6 Hi Wouter, You said: "From the page you reference, the :::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 :::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 i
RE: Unbound DNS on IPV6
Hi Wouter, You said: "From the page you reference, the :::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 :::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 Sent: 13 August 2018 09:18 To: unbound-users@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 :::0:0/96 notation is one that unbound can parse and use. The ::/96, is likely wrong, the /96 makes unbound ignore the lower bits, that you set to , 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: :::0:0/96 > > ? private-address: ::/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-ad
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 :::0:0/96 notation is one that unbound can parse and use. The ::/96, is likely wrong, the /96 makes unbound ignore the lower bits, that you set to , 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: :::0:0/96 > > ? private-address: ::/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 > >
