label compression inconsistencies

[hannesm]

I re-read the name compression code (while investigating the AXFR struggle), and what occured to me:

• the encoder inserts, independent of ~compress, all labels into the map (this is fine i think)
• the decoder emits a `P of int for all pointers, and then assumes them being in the map. this may not be the case for an (unknown) resource record type which is not decoded (i.e. treat as binary data)

the decoder thus should be made more robust and peek at the offset unless it is in the map. I as well remember some RFC describing which RR types allow compression -- SRV is a good example (2052 required it, 2782 disallows it).

in any case, the decoder should be made more robust (including test case). I don't think the encoder needs any change (it could be more conservative, and not even record the offsets (and thus not use them) of labels encoded by RR that have compression disabled. Eventually check with other software or people.

[hannesm]

In Section 4 of https://tools.ietf.org/html/rfc3597 it is clarified where compression may be used: owner name and the RFC 1035 resource records.