www.makemkv.com

Appears that lookups in the U.S may be having issues resolving hkdata.fairuse.org again. Yes, I'm aware it's a Russian site, yes I know how Geo-IP works, and yes I know the usual troubleshooting steps.

Right now nslookups are failing from multiple locations, and have been for a couple of days. Digs from MXToolbox, Google etc. all show the same thing - basically it appears that the A record is non-existent in the US:

id 6401
opcode QUERY
rcode NXDOMAIN
flags QR RD RA
;QUESTION
hkdata.fairuse.org. IN A
;ANSWER
;AUTHORITY
fairuse.org. 1687 IN SOA ns1.afraid.org. hostmaster.becnel.net. 2303230314 86400 7200 2419200 3600
;ADDITIONAL

Queries to fairuse.org resolve OK:

id 24787
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
fairuse.org. IN A
;ANSWER
fairuse.org. 3600 IN A 74.81.82.130
;AUTHORITY
;ADDITIONAL

Of course, it's entirely possible that the U.S. govt is doing something intentional. Can someone look into this, and does anyone know the IP so I can create a local hosts file entry as a workaround?

Thanks,
Bill

Absolutely did not mean to post this in the UHD discs forum - meant to post in the General MakeMKV discussion.

Admins: Feel free to move if necessary.

DNS work-arounds with pinpoint DNS Zones on the domain controllers and static DNS entry on the UTM/Firewall fail after trying hard. Ultimately, this solves the resolution issue, but connection timeout errors persist from hkdata.fairuse.org.

This doesn't seem to be a "US" problem; it's a generic DNS problem. I can't do the lookup from a server in Amsterdam.

And if we do some simple diagnostics...

These are meant to be nameservers, when asking the authoritative servers for org.
eg b0.org.afilias-nst.org. So lets ask these servers directly The same answer from ns2/3/4.

But Mike says this isn't needed; viewtopic.php?p=119282#p119282

While I cannot comment on exactly what the application relies on to pull down the latest HK, I can say that I have reams of firewall logs all showing that MakeMKV v1.17.3 absolutely attempts to resolve and hit hkdata.fairuse.org. And when that fails, the application produces an error indicating that "Automatic HK downloading is disabled or failed." This may be inconsequential or purely coincidental, but it does happen and the timing is suspect.

The workaround for me was to use a VPN tunnel to Japan. It worked fine from Asia, but failed from VPN exit points in Europe.

This then begs four questions:

1. If the application no longer relies on hkdata.fairuse.org, why does it repeatedly attempt to hit hkdata.fairuse.org?
2. If the application no longer relies on hkdata.fairuse.org, why does it produce the error that it does when lookups fail?
3. If the application no longer relies on hkdata.fairuse.org, why hasn't the code been updated to not attempt to hit hkdata.fairuse.org?
4. If the application no longer relies on hkdata.fairuse.org, what does the application code actually use to download the latest HK, so we can better troubleshoot these issues when they occur?

It's not that I don't believe knowledgeable folks like Woodstock, it's just that I have empirical data to the contrary.

Regards

Cannot resolve ip address for hkdata,fairuse,org in the UK either.

I also get latest hk not being able to download unless I use a VPN, then it works.

What I really want to know is what server Makemkv is looking for to download the HK file, so I can do some testing.

Does anyone know the server Makemkv is looking for, if it is not hkdate.fairuse.org?