I have found it impossible to get a fully green donut when running DNS Bench. A fully green donut shows the server has full rebinding protection:
https://www.grc.com/dns/operation.htm - Quote:
"The best possible protection is therefore represented by a full, unbroken, green outer ring signifying that all four network IP ranges are being blocked in both IPv4 and IPv6 formats. While no nameservers are providing this protection at the time of this new feature's release, it is our hope that, with time, many nameservers will be updated to do so. No new programming is required to provide this feature. It is simply a matter of updating the nameserver's configuration file."
This is why (I think/hope)
DNSBench.exe would need to modify the way it works for its functionality to work correctly.
A question). IPV4 Addresses in the form of ::ffff:x.x.x.x should never appear on the internet? Is this statement true/correct?
If the questions answer is yes and addresses in the form of ::ffff:x.x.x.x should never appear on the internet, then what DNSBench.exe is doing will never result in a central green dot with a full outer green circle.
The reason for this is that ::ffff:0:0/96 refers to all IPV4 address from 0.0.0.0 to 255.255.255.255 so when DNSBench.exe tries to verify IPV6 Internet connectivity it uses ::ffff:4.4.4.4#53 as the address but by definition above all IPV4 addresses in that format will be removed from the answer DNSBench.exe thinks there is no IPV6 internet connectivity. This conflicts with its findings when it tests IPV4 with 4.4.4.4#53 which works. This results in the "Not Consistent" message. This then translates into not outer circles either Blue or Green, so the user has no idea what is and is not correct.
If the answer to the question is no these addresses can appear on the internet, then we cannot use ::ffff:0:0/96 as the private address. This means we must define each IPV6 definition of IPV4 addresses in the format of ::ffff:x.x.x.x individually. To do this the following is required:
IPV4 Addresses:
private-address: 0.0.0.0/8 # Broadcast address
private-address: 10.0.0.0/8
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.168.0.0/16
become:
IPV6 Addresses:
private-address: ::ffff:0.0.0.0/104 # IPV4 /8
private-address: ::ffff:10.0.0.0/104 # IPV4 /8
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
The method here is you add the /n from IPV4 x.x.x.x/n to 96 and that gives the /n for the IPV6 ::ffff:x.x.x.x/n format.
Then you get the result as in the attached image. Which is what I have been trying to achieve, but its taken some sleuthing to get there.
So IMHO DNSBench.exe needs some work one way or the other both in the program itself and some changes to the documentation to help people do the right thing.
What is the best way to get Steve to fix this issue (I know I can hear everyone shout SQRL) but I feel sure that he would not want to have something misleading up on GRC.COM. It does appear to be a simple fix.
1). Remove the test for ::ffff:4.4.4.4#53 and use the results from the IPV4 or use a server that has a valid IPV6 address
2). Update the documentation to give the correct list of addresses as examples so people can configure their server(s) correctly.
There are other addresses in both the IPV4 and IPV6 ranges that would appear to be "private" apart from the common ones above.
for Linux OpenSuse has this information:
https://forum.opnsense.org/index.php?topic=1416.0
The info here is also confusing as it mentions for example fc00::/8 as one of the private IPV6 addresses and then talks about fc00::/7 in the comments - so which is it?
Ripe have some other information here but I think that this can be confusing if you don't understand IPV6 (which I still don't in full by any means)
https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-address-types/ipv6-address-types
You can also glean some information from here:
https://tools.ietf.org/html/rfc5156
I hope that all makes sense and helps.
I know Steve has been busy for a long time on other projects but hopefully there will be time at some point to resolve this issue.
Just edited this as I realised, I forgot to attach the image Thread originally posted 15th August 2018 http://www.grc.com/groups/techtalk:279461
https://www.grc.com/dns/operation.htm - Quote:
"The best possible protection is therefore represented by a full, unbroken, green outer ring signifying that all four network IP ranges are being blocked in both IPv4 and IPv6 formats. While no nameservers are providing this protection at the time of this new feature's release, it is our hope that, with time, many nameservers will be updated to do so. No new programming is required to provide this feature. It is simply a matter of updating the nameserver's configuration file."
This is why (I think/hope)
DNSBench.exe would need to modify the way it works for its functionality to work correctly.
A question). IPV4 Addresses in the form of ::ffff:x.x.x.x should never appear on the internet? Is this statement true/correct?
If the questions answer is yes and addresses in the form of ::ffff:x.x.x.x should never appear on the internet, then what DNSBench.exe is doing will never result in a central green dot with a full outer green circle.
The reason for this is that ::ffff:0:0/96 refers to all IPV4 address from 0.0.0.0 to 255.255.255.255 so when DNSBench.exe tries to verify IPV6 Internet connectivity it uses ::ffff:4.4.4.4#53 as the address but by definition above all IPV4 addresses in that format will be removed from the answer DNSBench.exe thinks there is no IPV6 internet connectivity. This conflicts with its findings when it tests IPV4 with 4.4.4.4#53 which works. This results in the "Not Consistent" message. This then translates into not outer circles either Blue or Green, so the user has no idea what is and is not correct.
If the answer to the question is no these addresses can appear on the internet, then we cannot use ::ffff:0:0/96 as the private address. This means we must define each IPV6 definition of IPV4 addresses in the format of ::ffff:x.x.x.x individually. To do this the following is required:
IPV4 Addresses:
private-address: 0.0.0.0/8 # Broadcast address
private-address: 10.0.0.0/8
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.168.0.0/16
become:
IPV6 Addresses:
private-address: ::ffff:0.0.0.0/104 # IPV4 /8
private-address: ::ffff:10.0.0.0/104 # IPV4 /8
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
The method here is you add the /n from IPV4 x.x.x.x/n to 96 and that gives the /n for the IPV6 ::ffff:x.x.x.x/n format.
Then you get the result as in the attached image. Which is what I have been trying to achieve, but its taken some sleuthing to get there.
So IMHO DNSBench.exe needs some work one way or the other both in the program itself and some changes to the documentation to help people do the right thing.
What is the best way to get Steve to fix this issue (I know I can hear everyone shout SQRL) but I feel sure that he would not want to have something misleading up on GRC.COM. It does appear to be a simple fix.
1). Remove the test for ::ffff:4.4.4.4#53 and use the results from the IPV4 or use a server that has a valid IPV6 address
2). Update the documentation to give the correct list of addresses as examples so people can configure their server(s) correctly.
There are other addresses in both the IPV4 and IPV6 ranges that would appear to be "private" apart from the common ones above.
for Linux OpenSuse has this information:
https://forum.opnsense.org/index.php?topic=1416.0
The info here is also confusing as it mentions for example fc00::/8 as one of the private IPV6 addresses and then talks about fc00::/7 in the comments - so which is it?
Ripe have some other information here but I think that this can be confusing if you don't understand IPV6 (which I still don't in full by any means)
https://www.ripe.net/manage-ips-and-asns/ipv6/ipv6-address-types/ipv6-address-types
You can also glean some information from here:
https://tools.ietf.org/html/rfc5156
I hope that all makes sense and helps.
I know Steve has been busy for a long time on other projects but hopefully there will be time at some point to resolve this issue.
Just edited this as I realised, I forgot to attach the image Thread originally posted 15th August 2018 http://www.grc.com/groups/techtalk:279461
Attachments
Last edited: