Inconsistent DNS truncation between SRV and AAAA record types
- 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
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