DNScope.io

[ChrisR]

The issue you found in the setup is from it looking for the active connection and it's failed because of the language difference.

I confirm, tested in a virtual machine with an English windows 11.

[idle]

Thanks for trying it:

That should be 2 for Auto start rather than 3 manual:
HKLM\SYSTEM\CurrentControlSet\Services\Dnscache,Start=2

you can run it with the cache active, it will flush it when you block an item but it you lock your machine or put it to sleep the items you blocked will slip through on wake up before the program gets chance to wakeup.

What I find remarkable is that it ends up blocking more than 90% of your normal traffic.

[idle]

V 0.7.4a
Added a proper installer.
Fully threaded network code
internal structure now partially lock free using atomics
Added 3.5 million domains to the block list.

1) You will need to restart your machine before it's 100% effective as the windows dns cache will still be active until the restart

2) You will also need to disable IPV6 if you want to trap IPV6 traffic, it's only temporary
https://dnscope.io/how-to-disable-ipv6-on-windows/

3) turn off secure dns in your browser. Go to setting tab and search for dns.

[idle]

Fully threaded network and set bloom filter to 1st block.

https://dnscope.io/idlefiles/DNScopeSetup_0.7.6.b.zip

[idle]

I was asked the other day why I'm displaying domains in reverse as in com.purebasic. The simple answer is that it uses less space in the trie and facilitates top level and sub domain blocking.

A lot of work is going into the cache speed and it's an incremental process, the focus so far has been on the bloom filter and squint trie performance. The max look up rates of the squint trie on my desktop is ~15,000,000 32 byte keys per second and the bloom filter rate is something like ~600,000,000 32 byte keys per second in theory which is it a bit of a pinch and slap yourself speed, it takes ~20ms to look up 1 million 32 byte keys, that's 50,000,000 keys per second per thread. It's quick.

So while that sounds great, it won't really make a huge difference overall to the cache response speed as that's somewhat limited by reading and writing to the network adapter. Wire shark has the cached reply taking around 0.00023 seconds or 230 micro seconds, it's better than milliseconds but is the additional effort worth the small gains, I don't know yet.

[idle]

Added block options and swaped so the Block is on the Left/Red/Port and the Allow is on the Right/Green/Starboard

[idle]

0.8.2b Fixed a cache refresh bug which delayed unblocking.
Added options to block with bloom and status
Status blocks domains that refuse a connection without reporting a status.

[idle]

enabled the auto save of personal block list.
https://dnscope.io/idlefiles/DNScopeSetup_0.8.32.b.zip

[idle]

v 0.8.33.b
fixed a cache renew bug
https://dnscope.io/idlefiles/DNScopeSetup_0.8.33.b.zip

[idle]

Dnscope seems to be bug free now, it's been running since the 6th of December over 38.33 hours 63,803 requests have been blocked out of the 76,551 dns requests made, cpu is < 0.01 memory ~88,000k

kernel time 32:42
user time 5:50
total 38:33



I was asked the other day how DNScope differs to PI hole and adguard, As far as I'm aware Pi hole and adguard use the dns sinkhole method, that is to substitute the ip address with an unreachable address such as 0.0.0.0 or 127.0.0.1
https://en.wikipedia.org/wiki/DNS_sinkhole
The issue with this method is that it wastes resources while the calling software waits for the time out to expire, which is 3 seconds for DNS, the calling software may even try again in that case and so the cycle continues.

DNScope on the other hand responds to a dns query with a standard dns error message that simply states there's no record, this results in the calling software giving up gracefully and it then moves on to the next item.

[idle]

Threaded main server, blocks and cache response times are generally sub < 1 millisecond but GUI doesn't reflect the true times. Next stage will be to eliminate thread start up times and use a thread pool.

Current performance is ~1200 queries per second from a single thread calling gethostbyname, which is comparable to PI holes claims of handling 100,000,000 request a day on a cloud server 72,000 p/min 4,320,000 p/h , 103,680,000 p/day
performance will probably be 3 times higher once the thread pools are operational simply as thread startup is very costly.
I'm ok with the speed for now.

Currently setup assigns a secondary DNS to the network adaptor and it can lead to leakage when the computer resumes from sleep. If your happy with the performance and it's not blocking things you can delete the 2nd entry in the adapters DNS settings or set it to 127.0.0.2, this will mean if DNScope closes you wont have any dns.

https://dnscope.io/idlefiles/DNScopeSetup_0.8.4.0.b.zip

[idle]

Is anyone interested in me open sourcing the project?

[firace]

Is anyone interested in me open sourcing the project?

I unfortunately haven't had a chance to test this tool yet, but it sounds extremely interesting. As for open sourcing, I guess it's a great idea, as it could help it reach a wider audience.

[idle]

I unfortunately haven't had a chance to test this tool yet, but it sounds extremely interesting. As for open sourcing, I guess it's a great idea, as it could help it reach a wider audience.

It will help to get PB coders looking at it and maybe some involved and it will also get google off my back. I understand people are reluctant to run exes on their dev machines, I get that.

My only reluctance to open source it is to share the code with the competition, I'm coming 10 years late to market and both Adguard and PI hole go about blocking the wrong way in my opinion. In terms of speed I think I'm way ahead of them and I can still get 3 to 4 times faster yet by eliminating thread start up times by using a thread pool, currently the cache response times are ~1 millisecond and a 3rd of that time is likely from spinning up threads. I estimate that it can handle ~200 to ~250 million requests a day but I need to fix a bottle neck in the GUI as it can't keep up but in bursts the speeds there.

It's ready to compile on OSX and Linux without major hassles, It's the config and setup that needs working on. I've already compiled it on OSX and it will work on Linux and eventually it will work on ARM M1 and PI4 once I've back ported the X64 ASM to pb or c.

[Caronte3D]

My only reluctance to open source it is to share the code with the competition...

Then, don't open source it.

Maybe you can spend some money on a marketing campaing, aimed to show the awesome speed compared with the competition.
People need to clearly see things like that or no one change to a new competitor.