Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

How to disable Type 65 (HTTPS) DNS requests for Safari (or any other stuff which use it) under Ventura

C

Czo

macrumors 6502
Original poster
Dec 30, 2008
437
274
Debrecen, Hungary
Anyone found a way, to prevent Safari from issuing Type 65 (HTTPS) DNS requests? When the Safari receives a valid Type 65 DNS answer to the query, it's ignoring completley what are configured in the /etc/hosts nor returned by the DNS server for A and AAAA records.

A great example is serials.ws, which is blocked on my network, but thier admins configured a proper Type 65 DNS reply. Regardless what i has ben wroted in the hosts file, this site can be loaded until Safari can get a valid reply to the Type 65 request.
 
bogdanw said:
Disable iCloud Private Relay https://support.apple.com/en-us/HT212614
and Hide IP address https://support.apple.com/guide/safari/privacy-sfri35610/16.1/mac/13.0
Click to expand...

Neither of this are enabled, and the only DNS server in the configuration is my local DNS (so no google or others are configured).

When i try to access a site, which is blocked, Safari sending this Type 65 record to my local DNS server, and because this supports this type of the query (unfortunately all of the dns servers in the chain are supports Type 65), forwards this request to thier upstream, and sends back the anwer. This is clearly visible on Wireshark in my Mac and with tcpdump on the router too.
 
I don’t understand what Safari is supposed to be doing wrong.
My understanding is that, when the user types hoho.ho :) in the address bar, Safari asks mDNSResponder what is the IP for that address, and mDNSResponder asks the set DNS server(s) to provide that information.
Safari can’t know if a site is configured for “a proper Type 65 DNS reply”, because Safari doesn’t know how to reach the site.
mDNSResponder usually connects to port 53.
 
bogdanw said:
I don’t understand what Safari is supposed to be doing wrong.
Click to expand...
I don't know whether it is "wrong", but Safari asks the DNS server for 3 DNS records - types A, AAAA and HTTPS.

Czo said:
A great example is serials.ws, which is blocked on my network
Click to expand...
I suggest it is incorrectly blocked. I use AdGuard Home as my DNS server and blocking serials.ws blocks all three DNS request (A, AAAA and HTTPS).

I am far from an expert, but I think you don't want to block all type HTTPS queries - it is a performance optimising query. Rather you should block serials.ws for all DNS types in your DNS server. Or add it to whatever content blocking software you use for Safari.
 
Last edited:
gilby101 said:
I don't know whether it is "wrong", but Safari asks the DNS server for 3 DNS records - types A, AAAA and HTTPS.
Click to expand...
That can probably be disabled in the Debug menu – WebKit Internal Features – Upgrade known hosts to HTTPS
 
bogdanw said:
Debug menu – WebKit Internal Features – Upgrade known hosts to HTTPS
Click to expand...
Are you saying that would stop Safari making DNS requests for Type 65 HTTPS DNS resource records? I will try it - first need to discover how to turn on the Debug menu (I only have Develop enabled).
bogdanw said:
Safari can’t know if a site is configured for “a proper Type 65 DNS reply”, because Safari doesn’t know how to reach the site.
Click to expand...
It is part of Safari finding out how to reach the site. Safari asks the local DNS server for a Type 65 resource record and (following the DNS resolving chain) if web site's DNS server has been configured with a Type 65 resource record then it will be returned to the local DNS server and then to Safari.
 
gilby101 said:
Are you saying that would stop Safari making DNS requests for Type 65 HTTPS DNS resource records? I will try it - first need to discover how to turn on the Debug menu (I only have Develop enabled).
Click to expand...
Close Safari, give Terminal Full Disk Access, then run
Code: 
defaults write com.apple.Safari IncludeInternalDebugMenu -bool YES
Or from Onyx – Parameters – Applications – Safari – Turn on the Debug menu
https://www.titanium-software.fr/en/onyx.html
gilby101 said:
It is part of Safari finding out how to reach the site. Safari asks the local DNS server for a Type 65 resource record and (following the DNS resolving chain) if web site's DNS server has been configured with a Type 65 resource record then it will be returned to the local DNS server and then to Safari.
Click to expand...
Regardless of what Safari asks, mDNSResponder should obey the settings in hosts and return 0.0.0.0 or whatever is set for that domain.
 
It's seems to me, that the option ("Upgrade known hosts to HTTPS") is not what i looking for.

I wrote "0.0.0.0 serials.ws www.serials.ws" to "/etc/hosts", and i took a restart on mDNSresponder. According to the Wireshark, ping and telnet did not invoke a dns request at all, but Safari did a Type65 request and after tried to connect to what was in the response.
 
bogdanw said:
Regardless of what Safari asks, mDNSResponder should obey the settings in hosts and return 0.0.0.0 or whatever is set for that domain.
Click to expand...
Czo said:
According to the Wireshark, ping and telnet did not invoke a dns request at all, but Safari did a Type65 request and after tried to connect to what was in the response.
Click to expand...
My guess as to what is happening:

mDNSResponder is honouring /etc/hosts for A and AAAA DNS requests, but not for HTTPS (type 65) which it is passing to your specified DNS server. It is then up to the DNS server to filter. On reflection this may not be surprising as /etc/hosts is just about simple name to IP translation, but not for more complex DNS types which do not expect just a simple IP address for the response.

And, some recognised filtering DNS providers have come unstuck with this and needed to fix it in their DNS servers.
 
Last edited:
gilby101 said:
My guess as to what is happening:

mDNSResponder is honouring /etc/hosts for A and AAAA DNS requests, but not for HTTPS (type 65) which it is passing to your specified DNS server. It is then up to the DNS server to filter. On reflection this may not be surprising as /etc/hosts is just about simple name to IP translation, but not for more complex DNS types which do not expect just a simple IP address for the response.

And, some recognised filtering DNS providers have come unstuck with this and needed to fix it in their DNS servers.
Click to expand...
Yep, that's why i would like to disable this. Previously the /etc/hosts was a good place to alter the DNS resolution, but this "new" request type will mess te classical hierarchy up (ie. i mean the "normal" way, which is to to execute gethostbyname before connecting to the socket).

I did not have any full or partiacl control over the resolving server, except only when i am at home. So, that's why i am looking something to disable this completely without the need, to alter the network configuration.
 
bogdanw said:
That can probably be disabled in the Debug menu – WebKit Internal Features – Upgrade known hosts to HTTPS
Click to expand...
Got the Debug menu and changed this. Does not make any difference. :( It must be referring to upgrade http to https in the URL - nothing to do with requesting DNS Type 65 (HTTPS) resource records.
 
I was able to partially resolve the issue by blocking HTTPS responses on the pi-holes that I use as DNS servers inside of my network.

Let me explain though why I view this as a problem and why the behavior of Safari is particularly annoying.

I put a regex expression into the pi-holes that blocks https requests for *.* requests with HTTPS as the request type.

Then I flushed the DNS cache on the Ventura Mac.

Then I observed that my Mac continues to sit and spin upon a connection request to the server with Safari which is causing a delay in making the connection... even though I can see that pi-hole immediatley offered up the A record for the host name.

I look at the pi-hole logs and see that Safari, with no input from me, has decided to change firewall.*.net which is my local/remote host (that I manage with local DNS on my internal network) into www.firewall.*.net which is not even the address I requested.

Safari literally "upgraded" the request assuming I'm a moron and need to connect to subdomain www for my request even though that's not even what I wanted to connect to and asked the network for both the A record and HTTPS record for a host that I DIDNT EVEN WANT. Safari thinks it's smarter than me, but I'm an engineer, so Safari can F off.

This behavior is stupid, arguably broken and should at least be something that can be disabled by the user.

The good news is that Chrome works fine, so I guess maybe I'll use that.

This is seeping into other things though, the terminal now also tries to resolve DNS this stupid way.
 
bogdanw said:
That is the point, as Cloudflare explains https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/

Instead of 0.0.0.0, have you tried a real, working IP address?
Like 142.250.184.238 (google.com)
Click to expand...
No, it does not matter.

Originally i discovered this behavior when i had to reach one of our partner's development server instance over a VPN connection, but the Safari ignored the A and AAAA reply of the advertised DNS server (i mean, the one which is was pushed by the VPN configuration), and it took the DNS resolve with my home's original DNS server with a Type 65 request. In mean time, Firefox and elinks was worked fine, and opened the site which i want to open.
 
It’s quite funny that both of you blame Safari for asking, but not your poorly configured pi and other holes for answering the requests. :)
There are already two threads for this kind of complaints
https://forums.macrumors.com/threads/rant-safari-is-a-literal-piece-of-beep.2332814/
https://forums.macrumors.com/threads/anyone-else-sick-of-safari.2348506/

By the way, both Chrome and Firefox have “Secure DNS”/ “DNS over HTTPS” turned on by default, bypassing the system's DNS settings.
https://support.google.com/chrome/answer/10468685?hl=en
https://support.mozilla.org/en-US/kb/firefox-dns-over-https
Happy holidays!
 
  • Like
Reactions: gilby101
bogdanw said:
It’s quite funny that both of you blame Safari for asking, but not your poorly configured pi and other holes for answering the requests. :)
There are already two threads for this kind of complaints
https://forums.macrumors.com/threads/rant-safari-is-a-literal-piece-of-beep.2332814/
https://forums.macrumors.com/threads/anyone-else-sick-of-safari.2348506/

By the way, both Chrome and Firefox have “Secure DNS”/ “DNS over HTTPS” turned on by default, bypassing the system's DNS settings.
https://support.google.com/chrome/answer/10468685?hl=en
https://support.mozilla.org/en-US/kb/firefox-dns-over-https
Happy holidays!
Click to expand...
This answer is cheeky and not helpful but I accept your surrender.

Chrome can easily be configured not to make these requests and the ask is to just provide the option in Safari to do the same.
 
The website mentioned in the first post seems to be down, I used cloudflare.com as an example.
restrictWeb.jpg
https://developer.apple.com/documentation/devicemanagement/parentalcontrolscontentfilter
 
All of this is known since BigSur ...
Does anybody know if this problem still exists now in 2023-07 ?

On BigSur I was not able to connect to /etc/hosts blocked domains
Tried multiple Domains on different Browsers
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back