SVCB / HTTPS - Draft IETF

[larivierec]

Hello, quick question for you does blocky currently support HTTPS/SVCB?

[kwitsch]

Not as custom mapping but they are passed through and could be filtered out.

[larivierec]

Passed through to the dns library that is used?

[kwitsch]

blocky uses(like most go based DNS services I know of) miekg DNS.
I'm fairly certain that it supports HTTPS records but I never worked with HTTPS or SVCB records before.

Even if the records aren't explicitly supported they should pass through unchanged if they aren't modified through the service (as far as I get the library).

[larivierec]

Alright then it should work already from what I understand I believe the library supports both

[larivierec]

btw turns out, the root for my question was #1273
there's a reply at the bottom of this page that for some reason disappears every day and then re-appears

https://forums.developer.apple.com/forums/thread/715416

related to DRAFT SVCB/HTTPS and the option in blocky

ede:
  enable: true

is not playing nice with iOS (Apple bug) 📦

quote from the page:

FYI: What I've seen by sniffing is that instead of a standard A record request (Type 1) they (Apple) have implemented a draft standard Type 65 query instead. This started sometime in the iOS 14 chain.

This smells a lot like what I've read above though I haven't read anyone actually root cause it. This is my experience, YMMV, usual disclaimers apply.

Most local DNS servers don't [yet] recognize this - after all, it is a draft standard - but Apple went ahead and implemented it anyway.

You can read the draft here:

https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-07.txt

What seems to happen - at least from the sniffing I've done - local DNS servers don't know what to do with the type 65 so they forward it to the rest of the internet assuming you are internet connected. iOS sometimes also issues a type 1 A request. The response from the rest of the internet must come back with at least something otherwise the name resolution - both of them - request fails.

In our case, we had to modify our local DNS server code to send a not found response back to the iOS devices. Then and only then will iOS listen to the A record that is also returned and process things like they used to before implementing this draft standard.

If the Type 65 request is not answered and the Type 1 is answered, the name resolution fails over to the next DNS server in the list.

I found a page at https://github.com/MikeBishop/dns-alt-svc/blob/main/svcb-implementations.md that talks about public services that are using this along with some local DNS servers that support the Type65 query draft standard.

Short version:

"iOS & macOS iOS 14 (September 2020) and macOS 11 (November 2020) support HTTPS/SVCB records. Type 65 (HTTPS) is requested for all URLSession or Network.framework connections that use an http or https scheme, or use ports 80 or 443."

You can check if this is what is biting you by sniffing the DNS requests between iOS and your local router; if you see the Type65 queries and fails or they go to a place that you don't want them to go to, then this is probably why your local DNS isn't working right..