DNS resolver fails on truncated UDP AAAA responses (missing TCP fallback)

[MrIron-no]

Description

The custom resolver in ircd_res.c appears to mishandle truncated DNS UDP responses (TC=1) for AAAA lookups.

This causes hostname validation failures for valid IPv6-only hosts where the AAAA answer is returned only after TCP retry.

Reproduction

Example IPv6-only hostname:

ipv6-only.example.net

System DNS tools resolve it correctly:

host -t AAAA ipv6-only.example.net

returns:

2001:db8:1234::42

Reverse lookup:

host 2001:db8:1234::42

returns:

ipv6-only.example.net

However ircd fails to resolve/validate the hostname.

Packet capture

Captured traffic from ircd:

PTR? 2.4.0.0....ip6.arpa
reply: PTR ipv6-only.example.net.

A? ipv6-only.example.net.
reply: NOERROR, 0 answers

AAAA? ipv6-only.example.net.
UDP reply: truncated (TC=1)

TCP retry:
AAAA ipv6-only.example.net. -> 2001:db8:1234::42

So:

• reverse PTR works
• AAAA exists
• DNS server behaves correctly
• TCP fallback succeeds
• ircd still fails resolution

Root cause

ircd_res.c uses UDP-only DNS transport:

os_socket(... SOCK_DGRAM ...)
os_sendto_nonb(...)
os_recvfrom_nonb(...)

There does not appear to be TCP fallback support for truncated replies.

The resolver currently treats:

TC=1

as equivalent to:

lookup failed / no answer

and for AAAA requests falls back to querying A:

case T_AAAA:
    if (request->state == REQ_AAAA)
        do_query_name(NULL, NULL, request->name, request, T_A);

This is incorrect.

A truncated DNS response means:

retry the same query over TCP

not:

AAAA lookup failed

Expected behavior

For IPv6 hostname verification:

PTR(ipv6) -> hostname
AAAA(hostname) -> same ipv6 address

If a UDP response has TC=1, the resolver should retry the same query over TCP.

Correct flow:

AAAA over UDP
TC=1
retry AAAA over TCP
receive AAAA
success

Current behavior:

AAAA over UDP
TC=1
treat as failure
fallback to A
A has no record
resolution fails

Suggested fix

Handle truncated replies explicitly:

if (header->tc) {
    retry same query over TCP
}

At minimum, do not fall back AAAA -> A when TC=1.

Environment

• FreeBSD 14.2
• ircu2 custom resolver (ircd_res.c)
• upstream recursive resolver (example: Cloudflare / local resolver)

Impact

This affects valid IPv6-only hosts and causes incorrect hostname resolution failures.

[empus]

Good find! Technically, TC=1 responses could happen with IPv4 lookups too. In practice with IRC, that may not be likely, but we should ensure this fix is not specific to AAAA lookups for IPv6 addresses.

[hiddn]

Good catch.

While the handling of "TC=1" is technically correct, ircu has historically been designed around being lightweight and efficient, especially in its resolver implementation. Supporting TCP fallback introduces an extra network round trip for lookups that previously remained UDP-only.

There is also historical precedent for server admins preferring to minimize DNS overhead entirely — some even disabled DNS resolution altogether ("F:DNS:FALSE") for performance.

I agree the current behavior is imperfect for certain IPv6-only and large-response cases, but I do not think unconditional TCP fallback should become mandatory behavior by default.

If a fix is implemented, I would strongly recommend making it an optional feature/configuration setting, disabled by default, so admins can choose the tradeoff between standards compliance and resolver/resource efficiency.

[empus]

It wouldn't be unconditional -- the condition is when the DNS resolver returns a TC=1 indicating truncation. It won't always happen.

It's hardly a performance concern with compute and network performance these days!

[hiddn]

There is still a possible attack vector (we've seen this from compromised ipv6 /32s).

I know I would want the option to disable this on my server if I hosted a public client server. It does not cost much to make it a feature.

If you want to discuss the attack vector issue, we can talk about it on IRC.