DNS Bench - Rebinding protection impossible to get a full green donut

  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

    /Steve.
  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)

RayG

Ray
Sep 18, 2020
4
1
UK
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
 

Attachments

  • DNSBenchOutput_4.PNG
    DNSBenchOutput_4.PNG
    2.1 KB · Views: 91
Last edited:
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.
You've taken the first step, Ray. <g>

Once I get GRC's eMailing system up (which will be happening very soon, since I need it in place for notifying SR6's owners about SR6.1) I would also like to notify the DNS Benchmark users of this change and our eMail list availability... so fixing this makes sense as a way of bringing people back for that opportunity. (y)

Thank you!