[Kresd] Name unresolution

Hello

Sometimes there is some domain which aren’t resolved.
Im trying to find out what is the cause and increase kresd verbosity.
Now i’m trying to understand the log. Any help regarding DS, NS, insecure and so on ?

Dec  8 09:56:12 turris kresd[24577]: [plan  ][00000.00] plan 'eu-west-3.console.aws.amazon.com.' type 'A' uid [26770.00]
Dec  8 09:56:12 turris kresd[24577]: [iterat][26770.00]   'eu-west-3.console.aws.amazon.com.' type 'A' new uid was assigned .01, parent uid .00
Dec  8 09:56:12 turris kresd[24577]: [cache ][26770.01]   => skipping unfit CNAME RR: rank 030, new TTL -331
Dec  8 09:56:12 turris kresd[24577]: [cache ][26770.01]   => skipping unfit NS packet: rank 030, new TTL 13
Dec  8 09:56:12 turris kresd[24577]: [cache ][26770.01]   => no NSEC* cached for zone: aws.amazon.com.
Dec  8 09:56:12 turris kresd[24577]: [cache ][26770.01]   => skipping zone: aws.amazon.com., NSEC, hash 0;new TTL -123456789, ret -2
Dec  8 09:56:12 turris kresd[24577]: [cache ][26770.01]   => skipping zone: aws.amazon.com., NSEC, hash 0;new TTL -123456789, ret -2
Dec  8 09:56:12 turris kresd[24577]: [zoncut][26770.01]   found cut: aws.amazon.com. (rank 010 return codes: DS 1, DNSKEY 1)
Dec  8 09:56:12 turris kresd[24577]: [resolv][26770.01]   => NS is provably without DS, going insecure
Dec  8 09:56:12 turris kresd[24577]: [select][26770.01]   => id: '01758' choosing: 'ns-932.amazon.com.'@'52.16.221.207#00053' with timeout 49 ms zone cut: 'aws.amazon.com.'
Dec  8 09:56:12 turris kresd[24577]: [resolv][26770.01]   => id: '01758' querying: 'ns-932.amazon.com.'@'52.16.221.207#00053' zone cut: 'aws.amazon.com.' qname: 'coNsoLe.aWs.AmazoN.cOM.' qtype: 'NS' proto: 'udp'
Dec  8 09:56:12 turris kresd[24577]: [select][26770.01]   => id: '01758' updating: 'ns-932.amazon.com.'@'52.16.221.207#00053' zone cut: 'aws.amazon.com.' with rtt 28 to srtt: 29 and variance: 2
Dec  8 09:56:12 turris kresd[24577]: [iterat][26770.01]   <= rcode: NXDOMAIN
Dec  8 09:56:12 turris kresd[24577]: [iterat][26770.01]   <= retrying with non-minimized name
Dec  8 09:56:12 turris kresd[24577]: [cache ][26770.01]   => not overwriting NS console.aws.amazon.com.
Dec  8 09:56:12 turris kresd[24577]: [iterat][26770.01]   'eu-west-3.console.aws.amazon.com.' type 'A' new uid was assigned .02, parent uid .00
Dec  8 09:56:12 turris kresd[24577]: [select][26770.02]   => id: '64548' choosing: 'ns-932.amazon.com.'@'52.16.221.207#00053' with timeout 49 ms zone cut: 'us-east-1.console.aws.amazon.com.'
Dec  8 09:56:12 turris kresd[24577]: [resolv][26770.02]   => id: '64548' querying: 'ns-932.amazon.com.'@'52.16.221.207#00053' zone cut: 'us-east-1.console.aws.amazon.com.' qname: 'eu-wESt-3.ConSOLe.Aws.AMaZon.cOM.' qtype: 'A' proto: 'udp'
Dec  8 09:56:12 turris kresd[24577]: [select][26770.02]   => id: '64548' updating: 'ns-932.amazon.com.'@'52.16.221.207#00053' zone cut: 'us-east-1.console.aws.amazon.com.' with rtt 28 to srtt: 29 and variance: 2
Dec  8 09:56:12 turris kresd[24577]: [iterat][26770.02]   <= rcode: NOERROR
Dec  8 09:56:12 turris kresd[24577]: [resolv][26770.02]   AD: request NOT classified as SECURE
Dec  8 09:56:12 turris kresd[24577]: [resolv][26770.02]   finished in state: 4, queries: 1, mempool: 16392 B

I’m trying to reach eu-west-3.console.aws.amazon.com and for now i have to bypass kresd to get to it.
But most disturbing is kresd who said : NOERROR !

Is it regarding DNSSec, should i update root keys ?

1 Like

On a quick look, I think it’s a bug in Knot Resolver, but not related to DNSSEC. I reproduced the issue and gathered more detailed logs. Thanks!

BTW, the root keys have only rotated once in the whole history.

3 Likes

Bug confirmed in old code. I have some fix already, but it needs more thought. (and I’m not sure how the fix will propagate to Turris OS afterwards)

1 Like

My bad, i was still on 5.3.0.
I discovered 5.3.2 was available.

I just update to 5.3.2 and unfortunatly i can confirm it still happens.

We are using the latest stable version of Knot Resolver (5.4.3) in Turis OS 5.3.2.

@vcunat prepared this PR into Knot Resolver:
https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1237

I backported it to the Turris OS packages repository:
https://gitlab.nic.cz/turris/os/packages/-/commit/3cf7e3ad13e19c46eba4adbb2e7d3c7b86b0f3cb

In other words, it means that the fix is going to be part of Turris OS 5.3.3. Hopefully, it will be released soon. It will be possible to try in the HBK branch in a few hours.

Thanks for your involvment @Pepe .
At this time, i’m correcting some of my mistake (ser2net config), i guess i’ll later found some others, so i won’t be “mad” to update to HBK now (even if i’m enought crazy to do this kind of stuff).

get some rest, you already do a wonderful job.

1 Like

Completely understood! Nothing to worry about. As soon as possible, we will try to push it to HBT and HBS because DNS resolving is an important part, and it is always good to have it fixed. :+1:

I should’ve said that for an immediate workaround you can switch to forwarding, e.g. in (re)Foris / DNS, and choose a target which does not suffer from this (in particular avoid the “CZ.NIC” option for now EDIT: fix deployed there).

1 Like

For reference, the fix landed in TOS 5.3.3.

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