hashicorp / hashicorp/consul

Inconsistent DNS truncation between SRV and AAAA record types

Open
#17,228 0 comments 0 reactions 0 assignees View on GitHub
theme/dns
Dominant language
Go
Stars
30.1k
Forks
4.6k
Avg merge
1d 18h
Merged PRs (30d)
39

Description

#### Overview of the Issue

When I try to resolve SRV and AAAA records, both display different truncation behaviour over UDP. SRV record only returns the complete response when forced over TCP, while AAAA records returns without specifying it. Please find the steps to reproduce the issue below.
---

#### Reproduction Steps

Steps to reproduce this issue, eg:

1. Create a consul dns record with enough number of SRV and AAAA / A records that can trigger a truncation
2. Run `dig foo.service.consul SRV @127.0.0.1 -p 8600`
3. See truncated output
4. Run `dig foo.service.consul AAAA @127.0.0.1 -p 8600`
5. See output without truncation
Eg:
```
$ dig _foobar.service.consul AAAA @127.0.0.1 -p 8600 +short | wc -l
111
$ dig _foobar.service.consul SRV @127.0.0.1 -p 8600 +short | wc -l
36
$ dig _foobar.service.consul SRV @127.0.0.1 -p 8600 +short +tcp | wc -l
111
```
Header information for
* SRV record query
```
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 42079
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Fri May 05 18:56:22 UTC 2023
;; MSG SIZE rcvd: 12
```
* AAAA record query
```
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 16501
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Fri May 05 18:56:33 UTC 2023
;; MSG SIZE rcvd: 12
```

### Consul info for both Client and Server

Client info

```
$ consul info
agent:
check_monitors = 0
check_ttls = 0
checks = 0
services = 0
build:
prerelease =
revision = 7ba4e1b+
version = 1.13.5+1
version_metadata =
consul:
acl = enabled
known_servers = 7
server = false
runtime:
arch = amd64
cpu_count = 96
goroutines = 70
max_procs = 96
os = linux
version = go1.19.4 X:boringcrypto
serf_lan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 311
failed = 0
health_score = 0
intent_queue = 0
left = 3
member_time = 894876
members = 3649
query_queue = 0
query_time = 2
```

```
Client agent HCL config
```

Server info

```
$ consul info
agent:
check_monitors = 0
check_ttls = 1
checks = 1
services = 1
build:
prerelease =
revision = 7ba4e1b+
version = 1.13.5+1
version_metadata =
consul:
acl = enabled
bootstrap = false
known_datacenters = 3
leader = false
leader_addr = [redacted]:8300
server = true
raft:
applied_index = 1728698523
commit_index = 1728698523
fsm_pending = 0
last_contact = 48.482445ms
last_log_index = 1728698524
last_log_term = 32257
last_snapshot_index = 1728694126
last_snapshot_term = 32257
latest_configuration = [redacted]
latest_configuration_index = 0
num_peers = 6
protocol_version = 3
protocol_version_max = 3
protocol_version_min = 0
snapshot_version_max = 1
snapshot_version_min = 0
state = Follower
term = 32257
runtime:
arch = amd64
cpu_count = 96
goroutines = 9714
max_procs = 96
os = linux
version = go1.19.4 X:boringcrypto
serf_lan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 311
failed = 0
health_score = 0
intent_queue = 0
left = 3
member_time = 894881
members = 3649
query_queue = 0
query_time = 2
serf_wan:
coordinate_resets = 0
encrypted = true
event_queue = 0
event_time = 1
failed = 0
health_score = 0
intent_queue = 0
left = 0
member_time = 31786
members = 17
query_queue = 0
query_time = 1
```

```
Server agent HCL config
```

### Operating system and Environment details

Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

### Log Fragments

NA.

Thank you.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the Consul DNS behavior with the provided `dig` commands against 127.0.0.1:8600, comparing SRV and AAAA responses over UDP and TCP. Trace the DNS query handling from that endpoint and verify that truncation is handled consistently for both record types, with regression coverage for the reproduced cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
debian, go, linux
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.