"automatic sdf downloading is disabled or failed" while decrypting

[video_newb]

C:\>nslookup hkdatastore.tk
Server: xxxxxxxxxxxxxxxx
Address: xxxxxxxxxxxxxxxx

Non-authoritative answer:
DNS request timed out.
timeout was 2 seconds.
Name: hkdatastore.tk
Addresses: 23.217.138.107
23.195.69.106


C:\>nslookup 23.217.138.107
Server: xxxxxxxxxxxxxxxx
Address: xxxxxxxxxxxxxxxx

Name: a23-217-138-107.deploy.static.akamaitechnologies.com
Address: 23.217.138.107

[theirongiant]

Thanks @SamuriHL. That was really helpful.

I see the problem now...

If you have an ad-blocking appliance such as a PiHole that does DNS filtering, or a router with "DNS Filtering" built-in, one of those devices *could* be intercepting your DNS queries (UDP:53). The queries are then passed upstream to the DNS server in your router (usually defaults to your ISP), which is ultimately the party responsible for deciding whether to block your connections to different sites.

This is possible even if you had manually specified something else on your computer.

In my case, I have a PiHole and an Asus AX88U router. DNS filtering is enabled on the router. This tells DHCP to instruct devices which DNS server they should use. I have set aside a list of devices that should use the router's built-in DNS, and others that should be told to use the PiHole instead. Either the feature is implemented incorrectly, or there is a bug, because I have exempted this computer from filtering and it still gives me the wrong result.

I was able to confirm this behavior by choosing a few random servers from https://public-dns.info and running them through dig. I kept getting the same result even for servers way outside my geo. Then I switched to a cellular hotspot and tried the same queries. Voilà! It worked.

What should you do to fix this in the long term? This could be really complicated depending on your situation. The primary reason you can't access the site is because your ISP has decided to block this domain, so you have a few options to restore access:

• Change your router's DNS settings in the "LAN" area
• Check your PiHole configuration to exempt your computer
• Use a cellular hotspot or VPN when running MakeMKV

The last option may be required if your ISP's modem / router does filtering without giving you an option to disable it.

[video_newb]

I tried the vpn route (Windscribe) but it got worse. With it running it no longer resolves hkdatastore.tk and makemkv still fails the download.

I have Spectrum as an ISP and am using their wifi router, so I cannot change the DNS servers on the router, but I have changed them on my computer and flushed dns, all to no avail.

Very stumped.

[BlueMac77]

I’ve also been getting the “Automatic SDF Downloading is disabled…” message but luckily still able to rip 4K UHDs successfully in Mac OSX. Avoided configuring the DNS as I’m worried it might mess up my internet connection.

[SamuriHL]

Ultimately this is the reason most of us use a different, secure dns server in the first place. People need to understand why secure dns is important. And why not using their ISP default dns is important. It's not about speed it's about control. Giving your ISP control over what sites you can and can't visit doesn't sit well with me. But that is what you're doing when you use their dns servers. Imo switching servers is not enough because the isp can still intercept unencrypted requests and modify them. This is why encrypted dns to a trusted server is so important. Please take some time and learn about this issue because it's only going to get worse going forward. And there is nothing Mike could do about it on his end. We have to take some responsibility and control over our own systems.

Sent from my SM-G975U using Tapatalk

[video_newb]

I thought using a vpn would allow me to bypass the ISP. Wouldn't I be tunneling past them and they'd not be able to intercept the encrypted data?

When I get on vpn and change my local dns to google (8.8.8.8 ) and flush the dns cache, I lookup hkdatastore.tk and it returns on-existent domain. This is supposedly the google dns server (at least it says it's dns.google at 8.8.8.8 ).

I'm stumped.

[Woodstock]

hkdatastore.tk is no longer the domain being looked for. MakeMKV asks the main server where the hash key file is stored, then accesses it via its current URL.

[video_newb]

I may have missed or mis-understood something in this thread then. What is the actual server being looked for by MakeMKV to download a new/updated sdf.bin file?

And, as a side note, why does the manual placing of the sdf file not work? Or not work as a replacement for the auto-download.

Thanks.

[Billycar11]

I may have missed or mis-understood something in this thread then. What is the actual server being looked for by MakeMKV to download a new/updated sdf.bin file?

And, as a side note, why does the manual placing of the sdf file not work? Or not work as a replacement for the auto-download.

Thanks.

That works for libredrive not for keys
There are 2 downloads
Sdf for drive
Hk for volume keys

[Woodstock]

What is the actual server being looked for by MakeMKV to download a new/updated sdf.bin file?

The actual server URL can change. I suspect that's because there are numerous examples of domains being taken over or deleted for a variety of reasons.

MakeMKV contacts this server (makemkv.com) to pick up some information, and the location of the latest hash key file. Someone posted the current location a few messages up in this topic.

[video_newb]

This is all information, but not helpful information. Someone mentioned use different dns server. I did, used a vpn to bypass my ISP intercepting and redirecting and whatever else, pointed my makemkv machine to google dns at 8.8.8.8. Nothing changed, still getting download error. What is even more interesting is my isp dns resolves hkdatastore,tk but google dns didn't. I understand that's not a source anymore but it's a data point that seems to indicate a different problem.

[video_newb]

This is all information, but not helpful information. Someone mentioned use different dns server. I did, used a vpn to bypass my ISP intercepting and redirecting and whatever else, pointed my makemkv machine to google dns at 8.8.8.8. Nothing changed, still getting download error. What is even more interesting is my isp dns resolves hkdatastore,tk but google dns didn't. I understand that's not a source anymore but it's a data point that seems to indicate a different problem.

C:\Windows\System32>nslookup
Default Server: dns.google
Address: 8.8.8.8
>
> hkdatastore.tk
Server: dns.google
Address: 8.8.8.8

*** dns.google can't find hkdatastore.tk: Non-existent domain
>
> makemkv.com
Server: dns.google
Address: 8.8.8.8

Non-authoritative answer:
Name: makemkv.com
Addresses: 2606:4700:30::6818:687b
2606:4700:30::6818:697b
104.24.104.123
104.24.105.123

>

[Woodstock]

This is all information, but not helpful information. Someone mentioned use different dns server. I did, used a vpn to bypass my ISP intercepting and redirecting and whatever else, pointed my makemkv machine to google dns at 8.8.8.8. Nothing changed, still getting download error. What is even more interesting is my isp dns resolves hkdatastore,tk but google dns didn't. I understand that's not a source anymore but it's a data point that seems to indicate a different problem.

What happens when you look up the domain reported a couple of days ago?

It is working for me.

Non-authoritative answer:
Name: hkdtst17.twilightparadox.com
Address: 91.224.23.225

[video_newb]

When I nslookup that name I get a loopback address. 127.0.0.54.

But I $^!& you not, the error stopped occurring maybe 20 minutes ago. I had even installed it on my work laptop and used a mifi device and had the same issue on it. But then went back to my makemkv machine and, lo and behold,
MakeMKV v1.14.5 win(x64-release) started

No download or sdf errors. I truly have no idea what happened within a 20 minute span, but it seems to be working.

I've been trying to rip Saw IV and had no luck. My DVD drive still won't recognize it for some reason (nor does it recognize V and VI) but it recognizes other DVD's so I'm guessing there's an issue with the SAW discs themselves (I through III all worked fine).

In any case, I'm crossing my fingers this is actually fixed and not just some fluke, but since I did nothing I know of to "fix it" I'm a little skeptical.

[kingston12]

Apologies in advance for my ignorance, but I can't understand most of the solutions in this thread!

Is it just safe to say that something is broken and will be fixed in a future update?