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@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@gmail.com> napísal(a):
>
> 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@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
--