apple / apple/swift-async-dns-resolver

dnssd: Garbage characters in concatenated TXT records

Open
#43 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Swift
Stars
160
Forks
33
PR merge metrics
No merged PRs in 30d

Description

`ptr.advanced(by: 1)` seen here: https://github.com/apple/swift-async-dns-resolver/blob/93136496c05fcb3f9324ce5dd59f8160078727db/Sources/AsyncDNSResolver/dnssd/DNSResolver_dnssd.swift#L423

works great for TXT records that are smaller than 255 chars _(are not concatenated)_

The problem arises here: quoting https://kb.isc.org/docs/aa-00356: `per RFC 4408 a TXT or SPF record is allowed to contain multiple strings, which should be concatenated together by the reading application`

As a single TXT record is allowed to have several strings, that are concatenated together, the concatenated TXT strings do not receive the same treatment with the first garbage byte being discarded by advancing the pointer by 1, resulting in incorrect output:
```
gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM9�7c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39�nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcn�Kq3C+Q+39nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XD�MWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/-avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6
```

while the TXT record itself is:
```
gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6gaMR1pL2IbR1Q6DdvfrycjmkazkC+cBfBYw31YQf8ULDmEHosIcTIEtHjfMzdwqezJliVs1tA+SQc6PpRpC6B7a5vlsgUhjTOttpeKhyu3czHbYiN5BpJkvhfa/2kEG56RIio0Tqcw2Uk9jofNHdp8GJujLVCDs/4OmoHKZk/H0=AD5A825925DC09677C5EA4EAa5HtTNSGcZ5Xq+3FytsZ+p/avjAuI5XDMWHoaRvcnKq3C+Q+39nds7LMKM97c7b6xc+6
```

Take a closer look at every 256th character in the output: `MKM9�7c7b` vs `MKM97c7b`

The byte is meant to represent the length of the following TXT record. And indeed, in case of 255 character strings the byte is equal to 255 (FF). The correct way to handle this would be to honour the length byte, and use it's value to read the data as a buffer.

The problem is reproducible on macOS/iOS/iPadOS with the dnssd backend.

Related: https://stackoverflow.com/questions/17330816/objective-c-dns-txt-record#comment25143465_17331454

Contributor guide

Open the contributing guide

Research direction

Start at Sources/AsyncDNSResolver/dnssd/DNSResolver_dnssd.swift around line 423, where the TXT record pointer is advanced. Trace how concatenated TXT strings are read and compare the output with the record shown in the issue. Done means concatenated records preserve every character, including the bytes at each 256-character boundary, without garbage characters.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
networking
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.