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
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.1IP 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.
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
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 
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