Single dot domain/DNS root zone query issue with containerized wireguard

I am running dockerized pihole and dockerized wireguard. wireguard seems to be working fine with pihole. But I noticed that I get a lot of single dot DNS root zone NS lookup queries in logs only if wireguard container is running.

Has anyone faced similar issue with wireguard or any other container/app? Any idea how to resolve/debug this?

What is a single-dot-domain in the query log? looks similar to my question but it has single dot A record queries

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.

Do you still see N/A as reply today?
Because if I query this, there is a whole answer section. Maybe you see this amount of requests because your client could not get any valid answer....

rockpi@rockpi-4b:~$ dig NS . @1.1.1.1

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> NS . @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61874
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			516769	IN	NS	a.root-servers.net.
.			516769	IN	NS	b.root-servers.net.
.			516769	IN	NS	c.root-servers.net.
.			516769	IN	NS	d.root-servers.net.
.			516769	IN	NS	e.root-servers.net.
.			516769	IN	NS	f.root-servers.net.
.			516769	IN	NS	g.root-servers.net.
.			516769	IN	NS	h.root-servers.net.
.			516769	IN	NS	i.root-servers.net.
.			516769	IN	NS	j.root-servers.net.
.			516769	IN	NS	k.root-servers.net.
.			516769	IN	NS	l.root-servers.net.
.			516769	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	516769	IN	A	198.41.0.4
a.root-servers.net.	516769	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	516769	IN	A	199.9.14.201
b.root-servers.net.	516769	IN	AAAA	2001:500:200::b
c.root-servers.net.	516769	IN	A	192.33.4.12
c.root-servers.net.	516769	IN	AAAA	2001:500:2::c
d.root-servers.net.	516769	IN	A	199.7.91.13
d.root-servers.net.	516769	IN	AAAA	2001:500:2d::d
e.root-servers.net.	516769	IN	A	192.203.230.10
e.root-servers.net.	516769	IN	AAAA	2001:500:a8::e
f.root-servers.net.	516769	IN	A	192.5.5.241
f.root-servers.net.	516769	IN	AAAA	2001:500:2f::f
g.root-servers.net.	516769	IN	A	192.112.36.4
g.root-servers.net.	516769	IN	AAAA	2001:500:12::d0d
h.root-servers.net.	516769	IN	A	198.97.190.53
h.root-servers.net.	516769	IN	AAAA	2001:500:1::53
i.root-servers.net.	516769	IN	A	192.36.148.17
i.root-servers.net.	516769	IN	AAAA	2001:7fe::53
j.root-servers.net.	516769	IN	A	192.58.128.30
j.root-servers.net.	516769	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	516769	IN	A	193.0.14.129
k.root-servers.net.	516769	IN	AAAA	2001:7fd::1
l.root-servers.net.	516769	IN	A	199.7.83.42
l.root-servers.net.	516769	IN	AAAA	2001:500:9f::42
m.root-servers.net.	516769	IN	A	202.12.27.33
m.root-servers.net.	516769	IN	AAAA	2001:dc3::35

;; Query time: 13 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sun Sep 18 19:56:16 CEST 2022
;; MSG SIZE  rcvd: 811

1 Like

The sheer number of those "." queries compared to the others makes me suspect something else going on.
Could you post output for below pls?

sudo grep 'query\[.* \. ' /var/log/pihole/pihole.log* | tail

FYI, those "." queries are popular for DDoS-ing:

Ow now my above reply was moved to this thread, above most likely doesnt apply for your situation as they seem not to be ANY queries (from the screenshots) that are mostly used for DDoS-ing.
But instead they are NS queries.
But still those NS replies are big enough to be used for DDoS-ing:

EDIT: Who/what is that 172.18.0.1 IP thats making those queries?

EDIT: Who/what is that 172.18.0.1 IP thats making those queries?

It's wireguard container. I don't see these NS dot enteries if I that container is stopped

Logs (after starting wireguard container):

Sep 19 20:55:07 dnsmasq[332]: Pi-hole hostname pi.hole is 192.168.50.11
Sep 19 20:55:08 dnsmasq[332]: query[NS] . from 172.18.0.1
Sep 19 20:55:08 dnsmasq[332]: forwarded . to 192.168.50.1
Sep 19 20:55:08 dnsmasq[332]: reply . is NODATA
Sep 19 20:55:10 dnsmasq[332]: query[NS] . from 172.18.0.1
Sep 19 20:55:10 dnsmasq[332]: forwarded . to 192.168.50.1
Sep 19 20:55:10 dnsmasq[332]: reply . is NODATA
Sep 19 20:55:11 dnsmasq[332]: query[NS] . from 172.18.0.1
Sep 19 20:55:11 dnsmasq[332]: forwarded . to 192.168.50.1
Sep 19 20:55:11 dnsmasq[332]: reply . is NODATA

I see NODATA as reply today. This is the latest screenshot after starting containerized wireguard (running on same pi that is hosting containerized pihole )

Logs are posted here : Single dot domain/DNS root zone query issue with containerized wireguard - #8 by armujahid

Most likely a process inside the Wireguard container or a VPN connected client is generating these queries.
Most likely its bombarding your DNS because there is no proper answer (NODATA).

Is 192.168.50.1 your router?
Whats output for below one run on a client (Windows/MacOS/Linux)?

nslookup -type=NS . 192.168.50.1

It should resemble below:

C:\>nslookup -type=NS . 10.0.0.1
Server:  router
Address:  10.0.0.1

Non-authoritative answer:
(root)  nameserver = j.root-servers.net
(root)  nameserver = k.root-servers.net
(root)  nameserver = h.root-servers.net
(root)  nameserver = g.root-servers.net
(root)  nameserver = l.root-servers.net
(root)  nameserver = i.root-servers.net
(root)  nameserver = e.root-servers.net
(root)  nameserver = f.root-servers.net
(root)  nameserver = m.root-servers.net
(root)  nameserver = c.root-servers.net
(root)  nameserver = b.root-servers.net
(root)  nameserver = a.root-servers.net
(root)  nameserver = d.root-servers.net

Yes 192.168.50.1 is my upstream DNS server/router. Check nslookup output with both my router and 1.1.1.1

And dot queries are generated even if no client is connected. So I am sure that these are originating internally from wireguard

Something weird going on if the query needs to switch from UDP to TCP to successfully get a reply.
The answer (239 bytes) should fit in a single UDP packet of default MTU size of 1500 bytes without truncating.
Below you see I can get an answer via UDP with the +notcp argument (and size 239 bytes):

pi@ph5b:~ $ dig +noall +answer +stats +notcp @localhost . ns
.                       65570   IN      NS      i.root-servers.net.
.                       65570   IN      NS      j.root-servers.net.
.                       65570   IN      NS      k.root-servers.net.
.                       65570   IN      NS      l.root-servers.net.
.                       65570   IN      NS      m.root-servers.net.
.                       65570   IN      NS      a.root-servers.net.
.                       65570   IN      NS      b.root-servers.net.
.                       65570   IN      NS      c.root-servers.net.
.                       65570   IN      NS      d.root-servers.net.
.                       65570   IN      NS      e.root-servers.net.
.                       65570   IN      NS      f.root-servers.net.
.                       65570   IN      NS      g.root-servers.net.
.                       65570   IN      NS      h.root-servers.net.
;; Query time: 9 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Sep 19 19:28:15 CEST 2022
;; MSG SIZE  rcvd: 239

I suspect 53 UDP not coming through at some point in the chain.
Am not sure if this is related to the issue but ...
make sure that for the Pi-hole Docker container both ports 53 TCP & UDP are port forwarded:

ports:
  - "53:53/tcp"
  - "53:53/udp"
  - "67:67/udp" # Only required if you are using Pi-hole as your DHCP server
  - "80:80/tcp"

And also make sure that no firewall is blocking 53 UDP & TCP.

2 Likes

make sure that for the Pi-hole Docker container both ports 53 TCP & UDP are port forwarded:

Yes both ports 53 TCP & UDP are forwarded.
My docker-compose

version: "3"

# More info at https://github.com/pi-hole/docker-pi-hole/ and https://docs.pi-hole.net/
services:
  pihole:
    container_name: pihole
    image: jacklul/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "67:67/udp"
      - "8080:80/tcp"
    environment:
      TZ: 'Asia/Karachi'
      ADMIN_EMAIL: myemail@something.com
      WEBPASSWORD: 'somepassword'
      WEBTHEME: 'default-dark'
      PIHOLE_DNS_: '192.168.50.1'
      FTLCONF_REPLY_ADDR4: '<v4addressofpi>'
      FTLCONF_REPLY_ADDR6: '<v6addressofpi>'
    # Volumes store your data between container upgrades
    volumes:
      - './etc-pihole/:/etc/pihole/'
      - './etc-dnsmasq.d/:/etc/dnsmasq.d/'
      - './etc-pihole-updatelists/:/etc/pihole-updatelists/'
    #dns:
    #- 192.168.50.1
    #- 1.1.1.1
    # Recommended but not required (DHCP needs NET_ADMIN)
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    # cap_add:
    #  - NET_ADMIN
    restart: unless-stopped

Also note that I am using DoT Cloudflare Zero Trust DNS (configured in my router). But note that issue was also occurring with public cloudflare's DNS that I was using while posting this question last year.

Let me search how to fix that MTU issue. I remember that pihole was showing some MTU related warnings some time ago but I couldn't find those warnings now.

That could be the other reason why it gets truncated switching to TCP.
If a box somewhere upstream only allows very small UDP packets, the query switches to fragmented TCP instead of UDP.
But thats highly unusual if this is happening already with a reply of only 239 bytes.

EDIT: Ow do you have a box that can run that dig command of mine with the +notcp argument against involved DNS IP's?
EDIT2: Can leave out the +noall +answer +stats arguments for a full reply.

ip addr is showing 1500 MTU on pihole and on my PC

Dig output from my PC that is using pihole:

❯ dig +noall +answer +stats +notcp @localhost . ns
;; communications error to 127.0.0.1#53: connection refused

❯ dig +noall +answer +stats +notcp . ns
.			6560	IN	NS	e.root-servers.net.
.			6560	IN	NS	d.root-servers.net.
.			6560	IN	NS	c.root-servers.net.
.			6560	IN	NS	f.root-servers.net.
.			6560	IN	NS	l.root-servers.net.
.			6560	IN	NS	b.root-servers.net.
.			6560	IN	NS	h.root-servers.net.
.			6560	IN	NS	m.root-servers.net.
.			6560	IN	NS	k.root-servers.net.
.			6560	IN	NS	i.root-servers.net.
.			6560	IN	NS	j.root-servers.net.
.			6560	IN	NS	g.root-servers.net.
.			6560	IN	NS	a.root-servers.net.
;; Query time: 3 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Sep 19 23:12:23 PKT 2022
;; MSG SIZE  rcvd: 811


Full reply:

❯ dig +notcp . ns

; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> +notcp . ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50418
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			6312	IN	NS	j.root-servers.net.
.			6312	IN	NS	c.root-servers.net.
.			6312	IN	NS	l.root-servers.net.
.			6312	IN	NS	b.root-servers.net.
.			6312	IN	NS	e.root-servers.net.
.			6312	IN	NS	k.root-servers.net.
.			6312	IN	NS	f.root-servers.net.
.			6312	IN	NS	a.root-servers.net.
.			6312	IN	NS	d.root-servers.net.
.			6312	IN	NS	g.root-servers.net.
.			6312	IN	NS	m.root-servers.net.
.			6312	IN	NS	i.root-servers.net.
.			6312	IN	NS	h.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	6312	IN	A	198.41.0.4
b.root-servers.net.	6312	IN	AAAA	2001:500:200::b
f.root-servers.net.	6312	IN	A	192.5.5.241
l.root-servers.net.	6312	IN	A	199.7.83.42
l.root-servers.net.	6312	IN	AAAA	2001:500:9f::42
j.root-servers.net.	6312	IN	AAAA	2001:503:c27::2:30
i.root-servers.net.	6312	IN	AAAA	2001:7fe::53
h.root-servers.net.	6312	IN	AAAA	2001:500:1::53
b.root-servers.net.	6312	IN	A	199.9.14.201
a.root-servers.net.	6312	IN	AAAA	2001:503:ba3e::2:30
i.root-servers.net.	6312	IN	A	192.36.148.17
d.root-servers.net.	6312	IN	A	199.7.91.13
k.root-servers.net.	6312	IN	AAAA	2001:7fd::1
j.root-servers.net.	6312	IN	A	192.58.128.30
e.root-servers.net.	6312	IN	A	192.203.230.10
e.root-servers.net.	6312	IN	AAAA	2001:500:a8::e
f.root-servers.net.	6312	IN	AAAA	2001:500:2f::f
g.root-servers.net.	6312	IN	A	192.112.36.4
c.root-servers.net.	6312	IN	A	192.33.4.12
c.root-servers.net.	6312	IN	AAAA	2001:500:2::c
m.root-servers.net.	6312	IN	AAAA	2001:dc3::35
k.root-servers.net.	6312	IN	A	193.0.14.129
m.root-servers.net.	6312	IN	A	202.12.27.33
d.root-servers.net.	6312	IN	AAAA	2001:500:2d::d
g.root-servers.net.	6312	IN	AAAA	2001:500:12::d0d
h.root-servers.net.	6312	IN	A	198.97.190.53

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Sep 19 23:16:32 PKT 2022
;; MSG SIZE  rcvd: 811

You need to run it against the IP thats giving you the NODATA status reply:

dig +notcp @192.168.50.1 . ns

1 Like

Something is wrong. My router is ROG Rapture GT-AC2900 running at 192.168.50.1

❯ dig +notcp @192.168.50.1 . ns
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> +notcp @192.168.50.1 . ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40527
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			510955	IN	NS	a.root-servers.net.
.			510955	IN	NS	b.root-servers.net.
.			510955	IN	NS	c.root-servers.net.
.			510955	IN	NS	d.root-servers.net.
.			510955	IN	NS	e.root-servers.net.
.			510955	IN	NS	f.root-servers.net.
.			510955	IN	NS	g.root-servers.net.
.			510955	IN	NS	h.root-servers.net.
.			510955	IN	NS	i.root-servers.net.
.			510955	IN	NS	j.root-servers.net.
.			510955	IN	NS	k.root-servers.net.
.			510955	IN	NS	l.root-servers.net.
.			510955	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	510955	IN	A	198.41.0.4
a.root-servers.net.	510955	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	510955	IN	A	199.9.14.201
b.root-servers.net.	510955	IN	AAAA	2001:500:200::b
c.root-servers.net.	510955	IN	A	192.33.4.12
c.root-servers.net.	510955	IN	AAAA	2001:500:2::c
d.root-servers.net.	510955	IN	A	199.7.91.13
d.root-servers.net.	510955	IN	AAAA	2001:500:2d::d
e.root-servers.net.	510955	IN	A	192.203.230.10
e.root-servers.net.	510955	IN	AAAA	2001:500:a8::e
f.root-servers.net.	510955	IN	A	192.5.5.241
f.root-servers.net.	510955	IN	AAAA	2001:500:2f::f
g.root-servers.net.	510955	IN	A	192.112.36.4
g.root-servers.net.	510955	IN	AAAA	2001:500:12::d0d
h.root-servers.net.	510955	IN	A	198.97.190.53
h.root-servers.net.	510955	IN	AAAA	2001:500:1::53
i.root-servers.net.	510955	IN	A	192.36.148.17
i.root-servers.net.	510955	IN	AAAA	2001:7fe::53
j.root-servers.net.	510955	IN	A	192.58.128.30
j.root-servers.net.	510955	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	510955	IN	A	193.0.14.129
k.root-servers.net.	510955	IN	AAAA	2001:7fd::1
l.root-servers.net.	510955	IN	A	199.7.83.42
l.root-servers.net.	510955	IN	AAAA	2001:500:9f::42
m.root-servers.net.	510955	IN	A	202.12.27.33
m.root-servers.net.	510955	IN	AAAA	2001:dc3::35

;; Query time: 91 msec
;; SERVER: 192.168.50.1#53(192.168.50.1) (TCP)
;; WHEN: Mon Sep 19 23:19:09 PKT 2022
;; MSG SIZE  rcvd: 1471

Yes definitely something wrong (10.0.0.1 is my router):

pi@ph5b:~ $ dig +notcp @10.0.0.1 . ns

; <<>> DiG 9.16.22-Raspbian <<>> +notcp @10.0.0.1 . ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56537
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       80487   IN      NS      e.root-servers.net.
.                       80487   IN      NS      m.root-servers.net.
.                       80487   IN      NS      j.root-servers.net.
.                       80487   IN      NS      d.root-servers.net.
.                       80487   IN      NS      k.root-servers.net.
.                       80487   IN      NS      l.root-servers.net.
.                       80487   IN      NS      g.root-servers.net.
.                       80487   IN      NS      c.root-servers.net.
.                       80487   IN      NS      b.root-servers.net.
.                       80487   IN      NS      a.root-servers.net.
.                       80487   IN      NS      h.root-servers.net.
.                       80487   IN      NS      i.root-servers.net.
.                       80487   IN      NS      f.root-servers.net.

;; Query time: 9 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Mon Sep 19 20:24:00 CEST 2022
;; MSG SIZE  rcvd: 239

After turning off Strict DNS over TLS setting in my router now DIG command output is fine. So truncate issue was related to strict DoT profile

❯ dig +notcp @192.168.50.1 . ns

; <<>> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> +notcp @192.168.50.1 . ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39963
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.				IN	NS

;; ANSWER SECTION:
.			517310	IN	NS	a.root-servers.net.
.			517310	IN	NS	b.root-servers.net.
.			517310	IN	NS	c.root-servers.net.
.			517310	IN	NS	d.root-servers.net.
.			517310	IN	NS	e.root-servers.net.
.			517310	IN	NS	f.root-servers.net.
.			517310	IN	NS	g.root-servers.net.
.			517310	IN	NS	h.root-servers.net.
.			517310	IN	NS	i.root-servers.net.
.			517310	IN	NS	j.root-servers.net.
.			517310	IN	NS	k.root-servers.net.
.			517310	IN	NS	l.root-servers.net.
.			517310	IN	NS	m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.	517310	IN	A	198.41.0.4
a.root-servers.net.	517310	IN	AAAA	2001:503:ba3e::2:30
b.root-servers.net.	517310	IN	A	199.9.14.201
b.root-servers.net.	517310	IN	AAAA	2001:500:200::b
c.root-servers.net.	517310	IN	A	192.33.4.12
c.root-servers.net.	517310	IN	AAAA	2001:500:2::c
d.root-servers.net.	517310	IN	A	199.7.91.13
d.root-servers.net.	517310	IN	AAAA	2001:500:2d::d
e.root-servers.net.	517310	IN	A	192.203.230.10
e.root-servers.net.	517310	IN	AAAA	2001:500:a8::e
f.root-servers.net.	517310	IN	A	192.5.5.241
f.root-servers.net.	517310	IN	AAAA	2001:500:2f::f
g.root-servers.net.	517310	IN	A	192.112.36.4
g.root-servers.net.	517310	IN	AAAA	2001:500:12::d0d
h.root-servers.net.	517310	IN	A	198.97.190.53
h.root-servers.net.	517310	IN	AAAA	2001:500:1::53
i.root-servers.net.	517310	IN	A	192.36.148.17
i.root-servers.net.	517310	IN	AAAA	2001:7fe::53
j.root-servers.net.	517310	IN	A	192.58.128.30
j.root-servers.net.	517310	IN	AAAA	2001:503:c27::2:30
k.root-servers.net.	517310	IN	A	193.0.14.129
k.root-servers.net.	517310	IN	AAAA	2001:7fd::1
l.root-servers.net.	517310	IN	A	199.7.83.42
l.root-servers.net.	517310	IN	AAAA	2001:500:9f::42
m.root-servers.net.	517310	IN	A	202.12.27.33
m.root-servers.net.	517310	IN	AAAA	2001:dc3::35

;; Query time: 24 msec
;; SERVER: 192.168.50.1#53(192.168.50.1) (UDP)
;; WHEN: Mon Sep 19 23:37:13 PKT 2022
;; MSG SIZE  rcvd: 811

But nslookup command is still showing same issue

❯ nslookup -type=NS . 192.168.50.1
;; Truncated, retrying in TCP mode.
Server:		192.168.50.1
Address:	192.168.50.1#53

.	nameserver = a.root-servers.net.
.	nameserver = b.root-servers.net.
.	nameserver = c.root-servers.net.
.	nameserver = d.root-servers.net.
.	nameserver = e.root-servers.net.
.	nameserver = f.root-servers.net.
.	nameserver = g.root-servers.net.
.	nameserver = h.root-servers.net.
.	nameserver = i.root-servers.net.
.	nameserver = j.root-servers.net.
.	nameserver = k.root-servers.net.
.	nameserver = l.root-servers.net.
.	nameserver = m.root-servers.net.

❯ nslookup -type=NS . 1.1.1.1
;; Truncated, retrying in TCP mode.
Server:		1.1.1.1
Address:	1.1.1.1#53

.	nameserver = a.root-servers.net.
.	nameserver = b.root-servers.net.
.	nameserver = c.root-servers.net.
.	nameserver = d.root-servers.net.
.	nameserver = e.root-servers.net.
.	nameserver = f.root-servers.net.
.	nameserver = g.root-servers.net.
.	nameserver = h.root-servers.net.
.	nameserver = i.root-servers.net.
.	nameserver = j.root-servers.net.
.	nameserver = k.root-servers.net.
.	nameserver = l.root-servers.net.
.	nameserver = m.root-servers.net.


Why do you want the router in the chain as upstream for Pi-hole?
Why not choose any of the default upstream DNS providers via the webGUI?

EDIT: Never mind:

I have no clue why this truncating is happening ... sorry.

No worries. Thanks for your time :slight_smile:

Why do you want the router in the chain as upstream for Pi-hole?

I wanted to give DoT or DoH a try. Since pihole doesn't natively support DoT/DoH that's why some sort of software is required between pihole and upstream dns.

Why not choose any of the default upstream DNS providers via the webGUI?

I have also tried that infact at the time of posting this question I was using cloudflare from webGUI.

Yup UDP query to 1.1.1.1 is also truncating. Probably this has to do with my ISP or country level firewall

1 Like