Weird domain name encoding - 0x80 prefix instead of 0xc0

[cosinekitty]

On customer systems I am encountering some unusual domain name encodings across various kinds of records, including NSEC and PTR. Here is a good example:

0000: 00 00 84 00 00 00 00 05 00 00 00 00 09 5f 73 65   ............._se
0010: 72 76 69 63 65 73 07 5f 64 6e 73 2d 73 64 04 5f   rvices._dns-sd._
0020: 75 64 70 05 6c 6f 63 61 6c 00 00 0c 00 01 00 00   udp.local.......
0030: 02 58 00 15 08 5f 61 74 65 6c 6e 65 74 04 5f 74   .X..._atelnet._t
0040: 63 70 05 6c 6f 63 61 6c 00 c0 0c 00 0c 00 01 00   cp.local........
0050: 00 02 58 00 13 06 5f 61 68 74 74 70 04 5f 74 63   ..X..._ahttp._tc
0060: 70 05 6c 6f 63 61 6c 00 c0 0c 00 0c 00 01 00 00   p.local.........
0070: 02 58 00 03 80 0c 00 c0 0c 00 0c 00 01 00 00 02   .X..............
0080: 58 00 03 80 0c 00 c0 0c 00 0c 00 01 00 00 02 58   X..............X
0090: 00 03 80 0c 00                                    .....

Notice the PTR record whose 16-bit length starts at offset 0x72. It says the record payload is 0x0003 bytes long. Where the domain name should be, we get the bytes 80 0c 00. Every RFC I read about DNS and MDNS says this should not be allowed. They all say the upper two bits of the first byte should be zeroes, or both should be ones. Anything else is "reserved for future use". But in this case 0x80 is 10000000 in binary.

My best guess is this a variant of domain name compression. It looks like it is similar to the 0xc0 pattern, only the referred string is a prefix, not a suffix. The 0x0c appears to be a pointer to the string "_services._dns-sd._udp.local.". Then the decoder presumably is supposed to come back to read the rest of the string at offset 0x76. The third byte 0x00 at offset 0x76 appears to terminate the string. I suppose more domain name text could appear here, hence my interpretation of a prefix encoding.

Has anyone else seen this sort of thing? I'd love to know where this encoding is documented. It really screws up decoding a domain name if you don't know about it. There probably needs to be a fix in Zeroconf/Dns/RecordReader.cs function ReadDomainName, if this can be nailed down.

[cosinekitty]

As a follow-up, I found this (apparently expired?) draft that defines the upper bits 10 as "local compression":
https://datatracker.ietf.org/doc/html/draft-ietf-dnsind-local-compression

There is also a 01 prefix for "extended label types" defined here:
https://datatracker.ietf.org/doc/html/rfc2671

I read in other RFC documents that these proposals may be expired/obsolete/deprecated. It's confusing to sort out.

[clairernovotny]

Is this still an issue?