# Are SVCB queries sent through pi-hole of blocking concern?
**URL:** https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983
**Category:** General
**Created:** [December 23, 2022, 9:29am UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983 "2022-12-23T09:29:21Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@slicedpi](https://discourse.pi-hole.net/u/slicedpi)
#### Post date: [December 23, 2022, 9:29am UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/1 "2022-12-23T09:29:21Z")
My IOS devices generate thousands of queries for \_dns.resolver.arpa which is of the SVCB type.
example of the output as below:
```auto
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?
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [December 23, 2022, 12:19pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/2 "2022-12-23T12:19:41Z")
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](https://doc.powerdns.com/authoritative/guides/svcb.html)).
It looks like apple is implementing this, you already specified IOS, [this](https://forum.netgate.com/topic/175347/_dns-resolver-arpa) netgate topic implies it's also used in [ventura](https://www.apple.com/macos/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:
```auto
.*;querytype=SVCB
```
result:
Since this, according to the topics I've read, is DoH / DoT related, you may be interested in [this](https://jpgpi250.github.io/piholemanual/doc/Block%20DOH%20with%20pfsense.pdf) (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.
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 23, 2022, 1:16pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/3 "2022-12-23T13:16:29Z")
> [@slicedpi](#):
>
> My IOS devices generate thousands of queries for \_dns.resolver.arpa which is of the SVCB type.
> [@slicedpi](#):
>
> considering they directly reveal my upstream providers
Please post some example queries, forwards and replies from your dnsmasq log at _ **/var/log/pihole/pihole.log** _.
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 23, 2022, 1:28pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/4 "2022-12-23T13:28:25Z")
> [@jpgpi250](#):
>
> I tried to read up on this, couldn't find much...
> **[Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)](https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/)**
>
> This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple...
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 23, 2022, 1:50pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/5 "2022-12-23T13:50:41Z")
> [@slicedpi](#):
>
> considering they directly reveal my upstream providers
With unbound as an upstream resolver, the answer is NXDOMAIN.
```auto
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
```
---
### Author:  [@chrislph](https://discourse.pi-hole.net/u/chrislph)
#### Post date: [December 23, 2022, 4:28pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/6 "2022-12-23T16:28:44Z")
> [@jpgpi250](#):
>
> Since this, according to the topics I've read, is DoH / DoT related
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](https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overview_Dec2021.pdf). 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](https://www.domaintools.com/resources/blog/the-use-cases-and-benefits-of-svcb-and-https-dns-record-types/) 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](https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/) 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.
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 23, 2022, 4:40pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/7 "2022-12-23T16:40:37Z")
> [@chrislph](#):
>
> From a Pi-hole admin point of view Apple's SVCB use shows up in the Query Log as HTTPS requests.
This is not the case:
> [@chrislph](#):
>
> Type 65 DNS Service Bindng (SVCB) HTTPS requests.
SVCB queries are type 64. HTTPS are type 65.
> **[List of DNS record types](https://en.wikipedia.org/wiki/List_of_DNS_record_types)**
>
> This list of DNS record types is an overview of resource records (RRs) permissible in zone files of the Domain Name System (DNS). It also contains pseudo-RRs. Other types of records simply provide some types of information (for example, an HINFO record gives a description of the type of computer/OS a host uses), or others return data used in experimental features. The "type" field is also used in the protocol for various operations.
> ANAME /
> apex CNAME /
> CNAME flattening /
> top-level redirection
> ...
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)](https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/11/))
> 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](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).
---
### Author:  [@chrislph](https://discourse.pi-hole.net/u/chrislph)
#### Post date: [December 23, 2022, 4:55pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/8 "2022-12-23T16:55:31Z")
> [@jfb](#):
>
> SVCB queries are type 64. HTTPS are type 65.
Thanks, yes good point same intentions but technically two separate RR types.
> [@jfb](#):
>
> I have never seen a valid reply for either - it is always NXDOMAIN.
If I ask my Pi-hole (which uses Unbound in recursive mode) it provides a valid reply for domains which have the relevant records.
```plaintext
$ 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
```
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 23, 2022, 4:57pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/9 "2022-12-23T16:57:33Z")
> [@chrislph](#):
>
> `dig @127.0.0.1 cloudflare.com type65`
I guess I've never specifically queried that domain for HTTPS records.
---
### Author:  [@chrislph](https://discourse.pi-hole.net/u/chrislph)
#### Post date: [December 23, 2022, 5:08pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/10 "2022-12-23T17:08:04Z")
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.
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 23, 2022, 5:10pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/11 "2022-12-23T17:10:26Z")
> [@chrislph](#):
>
> 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 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.
---
### Author:  [@slicedpi](https://discourse.pi-hole.net/u/slicedpi)
#### Post date: [December 23, 2022, 5:52pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/12 "2022-12-23T17:52:10Z")
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)
---
### Author:  [@chrislph](https://discourse.pi-hole.net/u/chrislph)
#### Post date: [December 23, 2022, 7:05pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/13 "2022-12-23T19:05:17Z")
> [@slicedpi](#):
>
> 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.
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](https://www.ietf.org/id/draft-ietf-add-ddr-10.html). This informs as to the availability of secure DNS services.
> **[Improve DNS security for apps and servers - WWDC22 - Videos - Apple Developer](https://developer.apple.com/videos/play/wwdc2022/10079/)**
>
> Discover the latest ways to ensure that DNS — the foundation of internet addressing — is secure within your app. Learn how to...
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.
```plaintext
$ 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.
---
### Author:  [@slicedpi](https://discourse.pi-hole.net/u/slicedpi)
#### Post date: [December 23, 2022, 10:34pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/14 "2022-12-23T22:34:54Z")
looks like nothing to be overly concerned about then. thanks to all who helped investigate.
edit: see further feedback from jpgpi250 and DL6ER below.
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [December 24, 2022, 1:50pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/15 "2022-12-24T13:50:48Z")
> [@slicedpi](#):
>
> looks like nothing to be overly concerned about then.
I DON'T agree with this statement.
Here's what I investigated, using the valuable info from [chrislph](https://discourse.pi-hole.net/u/chrislph).
I've been collecting DoH domain names and IP addresses for 2,5 years now, available on GitHub [here](https://github.com/jpgpi250/piholemanual).
In order to find the IP addresses that need to be blocked on the firewall, I run the following commands:
```auto
dig +tries=3 +time=4 +short
```
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)
```auto
dig +tries=2 +time=3 @"${IP}" _dns.resolver.arpa svcb +short
```
the SVCB info is returned, some examples:
```auto
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](https://discourse.pi-hole.net/uploads/short-url/7KJDn4g93YxdX5Vf1LgLX6YuAmt.zip) (5.9 KB)
here is the registered reply (SVCB info)
[svcb-data.zip](https://discourse.pi-hole.net/uploads/short-url/xlsFrycUZ9ATafS48ag5iGyuYgy.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](https://discourse.pi-hole.net/u/jfb)).
If pihole is using an upstream resolver such as dns.quad9.net (as mentioned by [slicedpi](https://discourse.pi-hole.net/u/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](https://jasonish-suricata.readthedocs.io/en/latest/rules/dns-keywords.html) 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?
---
### Author:  [@jfb](https://discourse.pi-hole.net/u/jfb)
#### Post date: [December 24, 2022, 4:04pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/16 "2022-12-24T16:04:31Z")
> [@jpgpi250](#):
>
> I'm currently looking into the option to block [opcode](https://jasonish-suricata.readthedocs.io/en/latest/rules/dns-keywords.html) type64 (SVCB) DNS requests
Why not do this in Pi-hole with the regex you previously listed?
`.*;querytype=SVCB`
---
### Author:  [@jpgpi250](https://discourse.pi-hole.net/u/jpgpi250)
#### Post date: [December 24, 2022, 4:50pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/17 "2022-12-24T16:50:11Z")
> [@jfb](#):
>
> Why not do this in Pi-hole with the regex you previously listed?
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).
---
### Author:  [@chrislph](https://discourse.pi-hole.net/u/chrislph)
#### Post date: [December 24, 2022, 5:51pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/19 "2022-12-24T17:51:52Z")
> [@jpgpi250](#):
>
> 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
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.
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [December 24, 2022, 6:27pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/20 "2022-12-24T18:27:43Z")
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.
> [@slicedpi](#):
>
> My IOS devices generate thousands of queries for \_dns.resolver.arpa which is of the SVCB type.
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".
> [@jpgpi250](#):
>
> I can't find the correct way to specify an SVCB record in unbound or NSD (used to test FTL functionality)
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:
```auto
pdnsutil add-record ftl. svcb TYPE64 "\# 13 000109706F72743D2238302200"
```
This has now been replaced by:
```auto
pdnsutil add-record ftl. svcb SVCB '1 port="80"'
```
> [@jfb](#):
>
> I believe these query types have been added to allow a client to do some discovery to see what services might be available.
This is spot on 👍 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):
> [@jpgpi250](#):
>
> For some reason, I can't resolve this (dig \_dns.resolver.arpa svcb), I get NXDOMAIN (before adding the regex, see below).
> [@chrislph](#):
>
> I similarly don't get a response using @slicedpi's opening query
Sure, this does not exist. It is a resolver extension, you will have more luck with
```auto
$ 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
```auto
$ 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
```
```auto
$ 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}"
```
---
### Author:  [@DL6ER](https://discourse.pi-hole.net/u/DL6ER)
#### Post date: [December 24, 2022, 6:28pm UTC](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983/21 "2022-12-24T18:28:20Z")
> [@chrislph](#):
>
> any app or device which might bypass your settings and use it could presumably do that anyway, eg with a Google server address.
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.
> [@jpgpi250](#):
>
> If pihole is using a recursive upstream, such as unbound, the result will be NXDOMAIN (as mentioned by [jfb](https://discourse.pi-hole.net/u/jfb)).
>
> If pihole is using an upstream resolver such as dns.quad9.net (as mentioned by [slicedpi](https://discourse.pi-hole.net/u/slicedpi)), a possibly "rogue" app could use this information to bypass pihole, using DoH / DoT / DoQ.
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.
> [@jpgpi250](#):
>
> Might I suggest an FTL option to block type64 (SVCB) queries, this for less experienced users, not using a recursive upstream?
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).
> [@chrislph](#):
>
> 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.
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.
[Next page](https://discourse.pi-hole.net/t/are-svcb-queries-sent-through-pi-hole-of-blocking-concern/59983.md?page=2)