Bug 13987 - KRESD - TLS forwarding doesn't work
Summary: KRESD - TLS forwarding doesn't work
Status: MODIFIED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: - Unknown - - Unknown -
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks: KRESD
  Show dependency tree / graph
 
Reported: 2026-05-23 13:35 UTC by Stefan Schantl
Modified: 2026-05-27 11:15 UTC (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Schantl 2026-05-23 13:35:54 UTC 
When configured to use TLS for to communicate with upstream DNS servers, no querries could be send and resolved.

When using unencrypted protocols this works quite well.
Comment 1 Michael Tremer 2026-05-26 15:31:50 UTC 
I cannot reproduce this. On my system, TLS connections are working just fine.

Could you please check for some logging output or other data?
Comment 2 Stefan Schantl 2026-05-26 19:38:45 UTC 
I got the following log output in "debug" logging mode when trying to resolver "x.com":

May 26 21:35:10 ipfire kresd[3163]: [plan  ][00000.00] plan 'x.com.' type 'A' uid [22325.00] 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.00]   'x.com.' type 'A' new uid was assigned .01, parent uid .00 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.01]   => skipping unfit NS RR: rank 002, new TTL -197891 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.01]   => trying zone: ., NSEC, hash 0 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.01]   => NSEC sname: range search miss (!covers) 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.01]   => skipping zone: ., NSEC, hash 0;new TTL -123456789, ret -2 
May 26 21:35:10 ipfire kresd[3163]: [plan  ][22325.01]   plan '.' type 'DNSKEY' uid [22325.02] 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.02]     '.' type 'DNSKEY' new uid was assigned .03, parent uid .01 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.03]     => satisfied by exact RRset: rank 060, new TTL 39006 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.03]     <= rcode: NOERROR 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.03]     <= parent: updating DNSKEY 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.03]     <= answer valid, OK 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.01]   'x.com.' type 'A' new uid was assigned .04, parent uid .00 
May 26 21:35:10 ipfire kresd[3163]: [plan  ][22325.04]   plan 'com.' type 'DS' uid [22325.05] 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.05]     'com.' type 'DS' new uid was assigned .06, parent uid .04 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.06]     => satisfied by exact RRset: rank 060, new TTL 85230 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.06]     <= rcode: NOERROR 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.06]     <= DS: OK 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.06]     <= parent: updating DS 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.06]     <= answer valid, OK 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.04]   'x.com.' type 'A' new uid was assigned .07, parent uid .00 
May 26 21:35:10 ipfire kresd[3163]: [plan  ][22325.07]   plan 'com.' type 'DNSKEY' uid [22325.08] 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.08]     'com.' type 'DNSKEY' new uid was assigned .09, parent uid .07 
May 26 21:35:10 ipfire kresd[3163]: [cache ][22325.09]     => satisfied by exact RRset: rank 060, new TTL 22647 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.09]     <= rcode: NOERROR 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.09]     <= parent: updating DNSKEY 
May 26 21:35:10 ipfire kresd[3163]: [valdtr][22325.09]     <= answer valid, OK 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.07]   'x.com.' type 'A' new uid was assigned .10, parent uid .00 
May 26 21:35:10 ipfire kresd[3163]: [resolv][22325.10]   => id: '31396' querying: '.'@'81.3.27.54#00853' zone cut: 'com.' qname: 'x.com.' qtype: 'A' proto: 'tcp' 
May 26 21:35:10 ipfire kresd[3163]: [worker][22325.10]   => connecting to: '81.3.27.54#00853' 
May 26 21:35:10 ipfire kresd[3163]: [defer ]  | IDLE 
May 26 21:35:10 ipfire kresd[3163]: [defer ]  |   deactivate idle 
May 26 21:35:10 ipfire kresd[3163]: [defer ]  | POLL 
May 26 21:35:10 ipfire supervisord: captured stdio output from cache-gc[3164]: Usage: 0.03%
May 26 21:35:10 ipfire kresd[3163]: [worker] => connected to '81.3.27.54#00853' 
May 26 21:35:10 ipfire kresd[3163]: [prlayr] [00000003] (out) Buffer submitted to grp 'DNS TCP' in wrap direction (3: DNS_MULTI_STREAM) 
May 26 21:35:10 ipfire kresd[3163]: [prlayr] [00000003] (out) Pushing IOVec 
May 26 21:35:10 ipfire kresd[3163]: [prlayr] [00000003] (out) Wire buffer submitted to grp 'DNS TCP' in unwrap direction (0: TCP) 
May 26 21:35:10 ipfire kresd[3163]: [io    ] => connection to '81.3.27.54#00853' closed by peer (end of file) 
May 26 21:35:10 ipfire kresd[3163]: [select][22325.10]   => id: '31396' noting selection error: '.'@'81.3.27.54#00853' zone cut: 'com.' error: 3 TCP_CONNECT_FAILED 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.10]   'x.com.' type 'A' new uid was assigned .11, parent uid .00 
May 26 21:35:10 ipfire kresd[3163]: [iterat][22325.11]   'x.com.' type 'A' new uid was assigned .12, parent uid .00 
May 26 21:35:10 ipfire kresd[3163]: [resolv][22325.12]   AD: request NOT classified as SECURE 
May 26 21:35:10 ipfire kresd[3163]: [resolv][22325.12]   finished in state: 8, queries: 4, mempool: 32800 B 
May 26 21:35:10 ipfire kresd[3163]: [prlayr] [00000001] (in) Buffer submitted to grp 'DNS UDP' in wrap direction (3: DNS_DGRAM) 
May 26 21:35:10 ipfire kresd[3163]: [prlayr] [00000001] (in) Pushing Buffer
Comment 3 Michael Tremer 2026-05-27 10:00:58 UTC 
Could you please capture this with tcpdump or tshark? We need to see whether this is a handshake problem or if the problem arises after the query has been sent.
Comment 5 Stefan Schantl 2026-05-27 11:15:54 UTC 
I can confirm with the applied changes TLS now works as expected.