dnssd: Garbage characters in concatenated TXT records #43
Description
ptr.advanced(by: 1) seen here:
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