fallback question - more activity than I expected

[bcookatpcsd]

Gitter seems to be acting up..

(knot-resolver in docker, host is Alpine linux should it matter with 'options single-request' in /etc/resolv.conf)

I found the fallback portion of the docs and was testing out at home before putting it in at work..

(kresctl config get > file)

fallback:
    enable: true
    servers:
    -   address:
        - 1.0.0.2
        - 1.1.1.2
        hostname: security.cloudflare-dns.com
        transport: tls
forward:
-   options:
        dnssec: false
    servers:
    - 192.168.88.252@531
    subtree:
    - onsite
    - 88.168.192.in-addr.arpa
-   options:
        dnssec: false
    servers:
    - 192.168.88.1@53
    subtree:
    - 188.onsite
    - 188.168.192.in-addr.arpa
-   options:
        dnssec: true
    servers:
    -   address:
        - 9.9.9.9
        - 149.112.112.112
        hostname: dns.quad9.net
        transport: tls
    -   address: 100.90.1.63@5357
    subtree: .

MTR says I'm 12ms away from Quad9

I was expecting to never see Cloudflare in my tcpdump

tcpdump -i eth0.88 -nnvv -K dst port 853 and 'host 1.0.0.2 or host 1.1.1.2'

as I sit here writing this:

09:58:33.202753 IP (tos 0x2,ECT(0), ttl 55, id 14449, offset 0, flags [DF], proto TCP (6), length 544)
    1.1.1.2.853 > 192.168.88.252.36138: Flags [P.], seq 1162:1654, ack 1041, win 16, options [nop,nop,TS val 4245309558 ecr 3296436169], length 492
09:58:33.202784 IP (tos 0x0, ttl 64, id 8167, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.88.252.36138 > 1.1.1.2.853: Flags [.], seq 1041, ack 1654, win 125, options [nop,nop,TS val 3296436387 ecr 4245309558], length 0
09:58:33.262984 IP (tos 0x0, ttl 64, id 30154, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.88.252.49276 > 1.0.0.2.853: Flags [SEW], seq 2624750266, win 64240, options [mss 1460,sackOK,TS val 2801758688 ecr 0,nop,wscale 9], length 0
09:58:33.279545 IP (tos 0x0, ttl 64, id 30155, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.88.252.49276 > 1.0.0.2.853: Flags [.], seq 2624750267, ack 3856791970, win 126, options [nop,nop,TS val 2801758705 ecr 4063106366], length 0
09:58:33.280111 IP (tos 0x2,ECT(0), ttl 64, id 30156, offset 0, flags [DF], proto TCP (6), length 708)
    192.168.88.252.49276 > 1.0.0.2.853: Flags [P.], seq 0:656, ack 1, win 126, options [nop,nop,TS val 2801758705 ecr 4063106366], length 656
09:58:33.299670 IP (tos 0x0, ttl 64, id 30157, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.88.252.49276 > 1.0.0.2.853: Flags [.], seq 656, ack 1449, win 132, options [nop,nop,TS val 2801758725 ecr 4063106387], length 0
09:58:33.299714 IP (tos 0x0, ttl 64, id 30158, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.88.252.49276 > 1.0.0.2.853: Flags [.], seq 656, ack 3284, win 139, options [nop,nop,TS val 2801758725 ecr 4063106387], length 0
09:58:33.300114 IP (tos 0x2,ECT(0), ttl 64, id 30159, offset 0, flags [DF], proto TCP (6), length 58)
    192.168.88.252.49276 > 1.0.0.2.853: Flags [P.], seq 656:662, ack 3284, win 139, options [nop,nop,TS val 2801758725 ecr 4063106387], length 6
^C
65 packets captured
65 packets received by filter
0 packets dropped by kernel

how does fallback work?

cache:
    ns-timeout: 5000ms
    prefetch:
        expiring: true
        prediction:
            period: 1
            window: 15m
    size-max: 64M

I found I was seeing a bunch of NXDOMAINS, and saw that when ns-timeout kicks in, that's is its response..

https://www.knot-resolver.cz/documentation/latest/config-fallback.html

Thank you in advance.

[vcunat]

You don't really need gitter, as it's a regular matrix room: https://matrix.to/#/#CZ-NIC_knot-resolver:gitter.im

[vcunat]

Fallback wasn't really designed (and tested) for forwarding. Perhaps your default forwarders don't reply very fast to some difficult queries, and the whole thing just isn't really tuned for this combination. ns-timeout won't do much in this case.

[bcookatpcsd]

https://github.com/CZ-NIC/knot-resolver/blob/master/modules/fallback/fallback.lua

(ignorantly) I saw the timeout and thought it was the ns timeout..

Any ideas for how to keep out of fallback?

Other than not define it?

Thank you in advance

[vcunat]

Generally I think for DoT-forwarding the timeout here could be increased
https://gitlab.nic.cz/knot/knot-resolver/-/blob/v6.2.0/lib/selection_forward.c#L10

or overall the strategy could be better than for UDP, but that wouldn't be an easy change.