20 Zář
2022
20 Zář
'22
8:31
Hello Blažej,
just a short comment on this - such awkward blocks actually happen
frequently and they are challenging to troubleshoot. They usually affect
only particular network ranges, therefore tools such as dnviz may even
mislead you to a wrong direction.
The trace is extremely useful and provides solid proof of what is
happening. The usual learning is that Knot resolver returns the answer for
a solid reason, though it may not be obvious at a first glance.
Best regards
Robert
On Mon, Sep 19, 2022 at 5:10 PM Blažej Krajňák <blazej.krajnak(a)gmail.com>
wrote:
Thanks to everyone.
It seems that our netblock is blocked and we do not receive responses
from 27.106.204.41 and 27.106.204.42.
Knot Resolver is acting correctly.
Blažej
po 19. 9. 2022 o 14:17 Blažej Krajňák <blazej.krajnak(a)gmail.com>
napísal(a):
--
Robert Šefr
CTO
robert.sefr(a)whalebone.io | +420608737930 | www.whalebone.io
Whalebone, s.r.o.
Jezuitská 14/13, 602 00 Brno
Czech Republic
What I see, the problematic IPs 27.106.204.41 and 27.106.204.42 look
to be "open resolvers" with high timeout rate. I think they are
misconfigured and misused what causes the overal problems.
dig google.com @27.106.204.41
; <<>> DiG 9.16.15-Debian <<>> google.com @27.106.204.41
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35456
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 60 IN A 93.46.8.90
;; Query time: 188 msec
;; SERVER: 27.106.204.41#53(27.106.204.41)
;; WHEN: Mon Sep 19 14:11:38 CEST 2022
;; MSG SIZE rcvd: 54
po 19. 9. 2022 o 13:55 Vladimír Čunát <vladimir.cunat(a)nic.cz>
napísal(a):
>
> So, the log shows that it won't connect even on TCP level. TCP is
tried
first at this point due to cache containing information about these
IPs timing out (over UDP).
>
> However, when I try from my network these IPs do reply, both over UDP
and
TCP. I'd probably look into traceroute, etc.
>
> --Vladimir
--