Are SVCB queries sent through pi-hole of blocking concern?

My IOS devices generate thousands of queries for _dns.resolver.arpa which is of the SVCB type.

example of the output as below:

dig _dns.resolver.arpa svcb

; <<>> DiG 9.16.33-Debian <<>> _dns.resolver.arpa svcb
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40248
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dns.resolver.arpa.            IN      SVCB

;; ANSWER SECTION:
_dns.resolver.arpa.     60      IN      SVCB    1 dns.quad9.net. alpn="dot" port=853 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe
_dns.resolver.arpa.     60      IN      SVCB    2 dns.quad9.net. alpn="h2" port=443 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe key7="/dns-query{?dns}"

;; ADDITIONAL SECTION:
dns.quad9.net.          60      IN      A       9.9.9.9
dns.quad9.net.          60      IN      A       149.112.112.112
dns.quad9.net.          60      IN      AAAA    2620:fe::fe

;; Query time: 19 msec
;; SERVER: 192.168.0.XX#53(192.168.0.XX)
;; WHEN: Fri Dec 23 08:37:17 GMT 2022
;; MSG SIZE  rcvd: 289

Would it be preferable to block these types of queries considering they directly reveal my upstream providers (for bypassing?) to IOS applications for supposed DoT and DoH purposes?

Very interesting, I tried to read up on this, couldn't find much...

It doesn't look like dnsmasq has a setting that would allow to specify an SVCB record.
I can't find the correct way to specify an SVCB record in unbound or NSD (used to test FTL functionality)
PowerDNS (used in the developers test environment) appears to be ready for this (see here).

It looks like apple is implementing this, you already specified IOS, this netgate topic implies it's also used in ventura.

For some reason, I can't resolve this (dig _dns.resolver.arpa svcb), I get NXDOMAIN (before adding the regex, see below).

Using the regex capability of pihole-FTL, it's possible to block all SVCB type queries:

.*;querytype=SVCB

result:

Since this, according to the topics I've read, is DoH / DoT related, you may be interested in this (Block DNS over HTTPS (DoH), using pfsense) project, the database currently contains 1417 unique DoH servers in the database.

Very much interested in the opinion of @DL6ER, regarding SVCB.

Please post some example queries, forwards and replies from your dnsmasq log at /var/log/pihole/pihole.log.

With unbound as an upstream resolver, the answer is NXDOMAIN.

dig _dns.resolver.arpa svcb

; <<>> DiG 9.16.33-Raspbian <<>> _dns.resolver.arpa svcb
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_dns.resolver.arpa.            IN      SVCB

;; AUTHORITY SECTION:
arpa.                   3107    IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2022122300 1800 900 604800 86400

;; Query time: 19 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 23 07:33:38 CST 2022
;; MSG SIZE  rcvd: 123

Is it? There are two situations where DNS and HTTPS crops up with recent Apple devices.

iCloud Private Relay. This is available with iCloud+ subscriptions and aims to provide enhanced privacy to users. It uses a form of DNS over HTTPS to encrypt DNS queries and route them through a pair of external relays. The idea is to separate the device and its IP address from the domain names that it is querying, to help prevent DNS providers from tracking users, and encrypt the queries to prevent networks from being able to watch DNS traffic.

Type 65 DNS Service Bindng (SVCB) HTTPS requests. These aim to enable service-related information to be passed to clients as part of the domain query. It's only a draft standard at the moment (see @jfb link above) but Apple has adopted it for HTTPS and as a result some providers have implemented support for it.

I'm not sure about this but I don't think there has to be any relationship between these two things. Apple may be using SVCB when implementing Private Relay but there's nothing about them which requires this association.

From a Pi-hole admin point of view Apple's SVCB use shows up in the Query Log as HTTPS requests. Apart from being visually noisy I don't see any benefit in blocking them, any more than there would be in blocking A record requests. They're valid resource record requests and, if supported by the service, offer advantages.

They're not related to DoH. The presence of HTTPS in the Query Log seems to make people think it's Apple devices bypassing Pi-Hole using DoH.

Private Relay, on the other hand, does bypass Pi-hole and doesn't show up at all since its purpose is exactly that – to essentially tunnel DNS requests to an external relay to be processed there instead of on your network.

If I've got something wrong here I welcome feedback from anyone else or the Pi-hole DNS ninjas.

This is not the case:

SVCB queries are type 64. HTTPS are type 65.

Both are used by Apple, and both are draft. I have never seen a valid reply for either - it is always NXDOMAIN.

I believe these query types have been added to allow a client to do some discovery to see what services might be available. As you noted, I don't think either is used specifically for DoH or DoT to bypass Pi-hole. In fact, Apple doesn't seem to be interested in doing so - they provided guidance for how to configure a network to prevent iCloud Private Relay from being active.

From the latest draft RFC (draft-ietf-dnsop-svcb-https-11 - Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs))

  1. Introduction

The SVCB ("Service Binding") and HTTPS RRs provide clients with
complete instructions for access to a service. This information
enables improved performance and privacy by avoiding transient
connections to a suboptimal default server, negotiating a preferred
protocol, and providing relevant public keys.

For example, HTTP clients currently resolve only A and/or AAAA
records for the origin hostname, learning only its IP addresses. If
an HTTP client learns more about the origin before connecting, it may
be able to upgrade "http" URLs to "https", enable HTTP/3 or Encrypted
ClientHello [ECH], or switch to an operationally preferable endpoint.
It is highly desirable to minimize the number of round-trips and
lookups required to learn this additional information.

The SVCB and HTTPS RRs also help when the operator of a service
wishes to delegate operational control to one or more other domains,
e.g. delegating the origin "https://example.com" to a service
operator endpoint at "svc.example.net". While this case can
sometimes be handled by a CNAME, that does not cover all use-cases.
CNAME is also inadequate when the service operator needs to provide a
bound collection of consistent configuration parameters through the
DNS (such as network location, protocol, and keying information).

This document first describes the SVCB RR as a general-purpose
resource record that can be applied directly and efficiently to a
wide range of services (Section 2). It also describes the rules for
defining other SVCB-compatible RR types (Section 6), starting with
the HTTPS RR type (Section 9), which provides improved efficiency and
convenience with HTTP by avoiding the need for an Attrleaf label
[Attrleaf] (Section 9.1).

Thanks, yes good point same intentions but technically two separate RR types.

If I ask my Pi-hole (which uses Unbound in recursive mode) it provides a valid reply for domains which have the relevant records.

$ dig @127.0.0.1 cloudflare.com type65

; <<>> DiG 9.16.33-Debian <<>> @127.0.0.1 cloudflare.com type65
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23770
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;cloudflare.com. IN HTTPS

;; ANSWER SECTION:
cloudflare.com. 204 IN HTTPS 1 . alpn="h3,h3-29,h2" ipv4hint=104.16.132.229,104.16.133.229 ipv6hint=2606:4700::6810:84e5,2606:4700::6810:85e5

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Dec 23 16:48:11 GMT 2022
;; MSG SIZE rcvd: 122

cloudflare_type65

I guess I've never specifically queried that domain for HTTPS records.

I suppose with Apple being an adopter it will be slowly but increasingly be taken up by service providers. The main point is that I'm checking that seeing them in the Query Log (whether successful or not) does not imply any connection with DoH or DoT? I similarly don't get a response using @slicedpi's opening query, but, for the reasons above, if I did I don't think I would be concerned by it.

I would agree.

I see a lot of hysteria (mostly on our Reddit forum) about Apple queries. If the domain has the word DNS in it or the query type is HTTPS, this is almost always a reason for the user to be convinced Apple is sneaking around Pi-hole by nefarious means.

To date, I haven't seen any reliable evidence that any Apple devices are bypassing Pi-hole DNS via encrypted DNS other than iCloud Private Relay. And, Apple provided guidance for how to handle that.

1 Like

They seem to occur every 30 minutes on average per iOS device.

FYI I have explicitly turned off Apple's Private relay on all my devices a long time ago.

some examples from pihole.log:

Dec 23 06:43:21 dnsmasq[25440]: query[SVCB] _dns.resolver.arpa from 192.168.0.XX
Dec 23 06:43:21 dnsmasq[25440]: reply _dns.resolver.arpa is SVCB
Dec 23 06:43:21 dnsmasq[25440]: reply _dns.resolver.arpa is SVCB
Dec 23 07:10:29 dnsmasq[25440]: query[SVCB] _dns.resolver.arpa from 192.168.0.XX
Dec 23 07:10:29 dnsmasq[25440]: forwarded _dns.resolver.arpa to 149.112.112.10
Dec 23 07:10:29 dnsmasq[25440]: reply _dns.resolver.arpa is SVCB
Dec 23 07:10:29 dnsmasq[25440]: reply _dns.resolver.arpa is SVCB

from the admin/queries.php?querytype=15 page
2022-12-23 06:34:28 SVCB _dns.resolver.arpa iPad.xxx OK (answered by dns10.quad9.net#53) BLOB (20.8ms)
2022-12-23 07:10:29 SVCB _dns.resolver.arpa iPhone.xxx OK (answered by dns10.quad9.net#53) BLOB (22.5ms)

It looks like this is standard recent iOS and macOS behaviour when joining a new network. The Apple Developer video below explains what's going on (13:45 onwards for specifics). In summary, when a device joins a new network it sends a SVCB query for _dns.resolver.arpa to determine if the DNS server supports DDR. This informs as to the availability of secure DNS services.

I think in your case you are using Quad9 as your Pi-hole upstream? And since Quad9 supports DDR, you see this reply when you query localhost, since Pi-hole is acting as a stub for Quad9.

$ dig @9.9.9.9 _dns.resolver.arpa type64
...
;; ANSWER SECTION:
_dns.resolver.arpa. 60 IN SVCB 1 dns.quad9.net. alpn="dot" port=853 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe
_dns.resolver.arpa. 60 IN SVCB 2 dns.quad9.net. alpn="h2" port=443 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe key7="/dns-query{?dns}"
...

DoT or DoH via DDR discovery looks to be separate from iCloud Private Relay.

Private Relay is a dedicated service for paying Apple users where DNS is encrypted and routed through an Apple server and a third-party content provider server and assigned a temporary IP address, to disassociate the Apple device and IP from its queries, preventing tracking and increasing privacy. It can be turned off or on as needed.

Whereas DoT or DoH is availble wherever supported, and apparently now checked for on any new network joined.

So to your opening question, I don't think you need be concerned that these queries reveal your upstream DNS server because a) they can be revealed with any normal query too, and b) any app or device which might bypass your settings and use it could presumably do that anyway, eg with a Google server address.

When browsers do this kind of test they play nice and request a "canary domain" to flag that they are doing this. Pi-hole recognises these and can respond to disable DoH.

I'm not at all clear on what process an Apple device follows, or if it can be controlled, or how to prevent an application from making its own queries. Is there a setting to toggle DDR off? So I still think there is some concern to be had, mainly over how to have control over these various probes and defaults.

Sorry for rambling but DoH and DoT keeps cropping up in various ways and getting a clear understanding of what is and isn't going on is useful for reference.

1 Like

looks like nothing to be overly concerned about then. thanks to all who helped investigate.
edit: see further feedback from jpgpi250 and DL6ER below.

I DON'T agree with this statement.

Here's what I investigated, using the valuable info from chrislph.

I've been collecting DoH domain names and IP addresses for 2,5 years now, available on GitHub here.

In order to find the IP addresses that need to be blocked on the firewall, I run the following commands:

dig +tries=3 +time=4 +short <domain>

this returns the IP address(es) and possible CNAME information of the domains, extracted from the lists.

now, using this query (${IP} is the result of the previous dig)

dig +tries=2 +time=3 @"${IP}" _dns.resolver.arpa svcb +short

the SVCB info is returned, some examples:

1 dns.khanhtran.me. alpn="h2" port=443 key7="/dns-query{?dns}"
1 dns.khanhtran.me. alpn="dot" port=853
1 dns.khanhtran.me. alpn="doq" port=784

1 dns.quad9.net. alpn="dot" port=853 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe
2 dns.quad9.net. alpn="h2" port=443 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe key7="/dns-query{?dns}"

1 3krkr.tonedtanya.com. alpn="h2" port=443 key7="/dns-query{?dns}"
1 3krkr.tonedtanya.com. alpn="doq" port=8853

As you can see, the SVCB info returned, contains info for DoH, DoT and DoQ, using not only ports 443 (DoH) and 853 (DoT), but also some none standard ports.

here is the list of all IPs (& domains) that reply to a SVCB query (from the DoH IP block lists)

svcb-servers.zip (5.9 KB)

here is the registered reply (SVCB info)

svcb-data.zip (4.8 KB)

In my view, the information of the first dig request can only be blocked, using a blocklist (pihole, RPZ or suricata), but the problem here is the domain must be in one of the source lists.

The second dig request will never be registered by pihole (target is @${ip} - bypasses pihole), unless, see later...

The second dig request will provide all the necessary information to a "rogue" app to use a DoH / DoT / DoQ DNS server, thus the ability to bypass pihole.

Two methods to prevent this:

  • block the target IP, using a firewall rule, that blocks all known (see lists) DoH / DoT / DoQ IP's, again, the limitation is the domain must be in one of the lists
  • the most effective way is probably to ensure all DNS requests, not originating from pihole are blocked, however...

If pihole is using a recursive upstream, such as unbound, the result will be NXDOMAIN (as mentioned by jfb).

If pihole is using an upstream resolver such as dns.quad9.net (as mentioned by slicedpi), a possibly "rogue" app could use this information to bypass pihole, using DoH / DoT / DoQ.

Because Apple devices appear to behave, sending the SVCB query to the configured DNS server (pihole), using the regex, mentioned earlier, will prevent any application using the provided SVCB info (blocked by regex), however, warning, I don't know if SVCB data is used to provide other info than the currently provided DNS info (see file), it may work against you in the future.

If the SVCB info is retrieved from another server than pihole, this information could be used to provide a build in dns client with the necessary info to bypass pihole.

Conclusion:

  • the regex, provided earlier, only works if the client uses the system configured DNS server (like apple devices appear to do).
  • to prevent apps and devices to retrieve SVCB info from other dns servers, it is necessary to configure the firewall to redirect all DNS queries, not originating from pihole, to pihole.
  • port 853 appears to be the only port, used for DoT
  • several ports need to be blocked to block DoQ (853, 784, 8853 in the SVCB results)

I'm currently looking into the option to block opcode type64 (SVCB) DNS requests, using suricata, no luck so far...

DL6ERs opinion would be highly appreciated. Might I suggest an FTL option to block type64 (SVCB) queries, this for less experienced users, not using a recursive upstream?

Why not do this in Pi-hole with the regex you previously listed?

.*;querytype=SVCB

As explained, once the app / device has obtained the IP address, using a regular A or AAAA query, it will than retrieve the SVCB data from that address, apple devices appear to be the exception (svcb query sent to system configured dns). e.g. example:

  • dig A dns.quad9.net -> 9.9.9.9
  • dig @9.9.9.9 _dns.resolver.arpa svcb

pihole doesn't see the second query, unless firewall redirection (to pihole) is working, thus the regex isn't applied. A lot of users don't have firewall redirection implemented (user doesn't know how to or firewall can't - device limitation).

Just to make things clear: the regex + firewall redirection should be an effective method to block all svcb queries. I always try to have multiple solutions for a given problem, hence, the suricata solution (suricata rule to reject dns queries, opcode type 64).

That's not the workflow I'm seeing. I'm seeing a new device joins the network and requests _dns.resolver.arpa SVCB from the DNS server(s) on the network, ie Pi-hole. This is where it can be blocked if desired using your original regex. If it is not blocked it fails because it's NXDOMAIN (if DDR/SVCB is not supported) or it's a SERVFAIL because the result is some variant of BOGUS (presumably an artifact of signatures coming via Pi-hole and not directly from the external server).

I tested all the DNS servers available in Pi-hole one by one plus Unbound locally and had only these results. I wasn't able to obtain any service records at all from any external server via Pi-hole, but was able to obtain them when querying the external servers directly.

If clients are performing their own direct DDR queries to external servers to establish encrypted DNS, that's not a Pi-hole problem, it's a network security problem, and needs to be addressed with policies and tech such as a firewalls and proxies – things which are missing from a typical home Internet setup.

It looks like encrypted DNS is well-intentioned but increasingly causing a headache for network admins and corporate IT dealing with devices bypassing network and company policies, causing liability and security concerns. Not to mention the annoyance of DNS moving up into the HTTPS space. And it looks like those concerns are starting to show themselves in the home now too.

I've been pinged here, sorry, it took some time. I'll go through from the top and put comments where I have some. I apologize in advance if this creates a mess, hopefully I'll have to say something interesting for anyone here.

This is quite an obvious bug. There is no need to query this multiple times. Maybe it could be updated once in a while but more on the order of "every few hours", surely not "thousands of queries".

You can always specify the raw (pre-encoded) form of DNS records, as we did here before a PowerDNS version with native HTTPS/SVCB support came available, see RFC3597 "Handling of Unknown DNS Resource Record (RR) Types" for reference.

As you specifically mentioned PowerDNS, let me quickly quote the two relevant lines from our test/pdns/setup.sh here. We used before:

pdnsutil add-record ftl. svcb TYPE64 "\# 13 000109706F72743D2238302200"

This has now been replaced by:

pdnsutil add-record ftl. svcb SVCB '1 port="80"'

This is spot on :+1: It can only deliver information by the resolver you are using anyway - but, yes, it has the potential to give them a shortcut bypassing your Pi-hole (see IP hints in the reply by 1.1.1.1 and 9.9.9.9 below):

Sure, this does not exist. It is a resolver extension, you will have more luck with

$ dig _dns.resolver.arpa svcb @8.8.8.8 +short
1 dns.google. alpn="dot"
2 dns.google. alpn="h2,h3" key7="/dns-query{?dns}"

or

$ dig _dns.resolver.arpa svcb @1.1.1.1 +short
1 one.one.one.one. alpn="h2" port=443 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001 key7="/dns-query{?dns}"
2 one.one.one.one. alpn="dot" port=853 ipv4hint=1.1.1.1,1.0.0.1 ipv6hint=2606:4700:4700::1111,2606:4700:4700::1001
$ dig _dns.resolver.arpa svcb @9.9.9.9 +short
1 dns.quad9.net. alpn="dot" port=853 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe
2 dns.quad9.net. alpn="h2" port=443 ipv4hint=9.9.9.9,149.112.112.112 ipv6hint=2620:fe::fe key7="/dns-query{?dns}"

Very true, they can use use the hard-coded addresses and won't have to search for them. This can only be solved at the (router) firewall level and has nothing to do with SVCB/HTTPS RRs.

I agree on this, however, also as said above, they can do so even without this by simply using hard-coded addresses. Sure, this could be a mechanism to distribute "new" IP addresses - which are not blocked yet - but this can also be done by much easier means such as simply asking some HTTPS API that returns resolver details. I'm pretty sure there are, e.g., Google APIs whose IP addresses you typically don't want to block for their various services to work as expected.

This could of course and even easily be done, but - forgive me - I'm not yet convinced. Sure, looking at the FTL config file documentation one might think we are not afraid to add more options, however, we will be ready to support them in the long run. These options should be meaningful also in 4+ years from now. If we add an option BLOCK_SVCB=true will this eventually lead to a whole zoo of similar options once we decide we also want to block other types? (note: when I'm saying "not convinced" this does NOT mean we won't do it, we're still in the "collecting more thoughts on this" phase).

Yes, and it's not necessarily a good thing. In fact, it is only pseudo-security / pseudo-privacy. Whom are they trying to hide from? The ISP? Or intelligence agencies? By sending your queries encrypted to Google/Cloudflare/etc. they will still see everything. And the other parties will then still see to which servers your devices are connecting to immediately afterwards. The only thing we are really talking about here is bypassing but, as has been said many times now, this can easily (and actually much easier) be done using other means as simple as hard-coding a list of IP addresses or asking some public API.

1 Like