Https-dns-proxy does not resolve some domains

I just noticed that https-dns-proxy does not reserve some domains. For example, if I have https-dns-proxy running, I can not resolve express-scripts.com. I am sure there were other domains in the past that couldn't be resolved but until now I did not realize what's going on.

I have tried to change the configured resolvers but nothing works. Simply stopping the service restores the ability to resolve this host. For now, I listed this domain and a resolver in the additional servers file of the dnsmasq but if there is a more appropriate solution, I would appreciate suggestions.

I use htps-dns-proxy with cloudflare/quad9 and can resolve this domain.

2 Likes

Me too :+1:

1 Like

@woland66 What version of Openwrt are you running and the uptime?

Works good here with Cloudfare.

I have deleted the old configuration, set up cloudflare as the only resolver and restarted the router but the problem is still there.
I am running openwrt 24.10.0 on gl.iNet GL-MT6000. Https-dns-proxy is version 2023.12.26-r4.

Any troubleshooting suggestions?

Are you using any router based adblocker ?

I am running banip but stopping banip does not change anything. On the other hand, stopping https-dns-proxy does restore the name resolution for this domain.

Tried querying the same FQDNs directly using nslookup, from the clients and router, to bypass H-D-P ?

nslookup express-scripts.com returns nothing with h-d-p running. Stopping h-d-p and running nslookup from a client returns the IP address. I need to resolve the hostname from a client before it resolves from the router itself but I'm guessing this is between me being impatient and the cache(?).

That's not what you were asked to test.

Then I misunderstood. Could you clarify what I should test?

If we assume your H-D-P hosts also have unencrypted DNSes, run nslookup express-scripts.com [IP of DoH server].

Or maybe your ISP has blocked access via DPI :slight_smile:
it's just that for some reason no one ever considers this option :slight_smile:

That's probably because it's a dumbass reason which makes no sense. If (and that's a big if) the ISP was involved then you would expect other encrypted lookups to fail. You would would also expect unencrypted lookups for the same sites to also fail.

what other non-encrypted searches?
i think you just haven't come across dpi yet, so you have this opinion.
you probably think that https will save you from dpi? :slight_smile:
what he needs to do is check whether the ip address is coming or not.
install the LanWhoIs program
type in the link and see if the ip is coming, then the problem is something else.
It happens that the EDNS may be turned on incorrectly on the dns server itself, then the ip address will be sent and the page will not open either.
There are millions of options :slight_smile:
therefore, you can enumerate indefinitely and https-dns-proxy definitely has nothing to do with it.

So you think the ISP is using dpi to block the lookup of one specific site, but doesn't care if you lookup the same site via a non-encrypted lookup. Right...

The only thing the OP needs to do in relation to the nonsense you're spouting is ignore it.

The only thing the author should do is to reconsider the views, but definitely not to focus on you words
You look more like fluder, and I've never seen you help anyone, you always break into a conversation and start getting smart.

Sorry, I was not clear: "nslookup express-scripts.com dns-server" works. In fact, this is my workaround for now: I put "server=/express-scripts.com/dns-server" in the /etc/dnsmasq.servers and enabled additional server files in the "dhcp and DNS" section of the settings.

One of the reasons I want to find a better solution is the recollection that I must have encountered this problem with some other websites in the past and I don't want to be adding them to that file one by one (even if the problem is relatively rare).

But the ISP doesn't block encrypted DNS lookup for any other hostname, doesn't block unencrypted lookup for this hostname, and doesn't block visits to that host once its IP is looked up. This is not impossible but it would have been a dumb ISP.