The method of compression that RFC1035 uses is error-prone, and, if 
implemented incorrectly, vulnerable to security problems.

In order to minimize these security problems, MaraDNS implements
compression in the following manner:

* As the RFC1035 packet is being processed, we look for compression pointers
  in Domain name labels.

* If such a label is found, we make a note of where the label is.

* We reset our pointer to the location of the domain label, as long as it 
  does not move us forward.

* We assume that the compression pointer points to a domain label.  In
  the interest of performance, and RFC1035 complience, we do not verify this.

* If the resulting expanded string is over 256 octets long, we consider it
  an error condition.  We break the loop as soon as the string is more than
  256 octets long.

Other notes about RFC1035 compression:

* The problem with compression is that the DNS server needs to know the
  exact format of each and every RR it receives that uses compression.
  There have been DNS servers that compress non-RFC1035 RRs.  For example, 
  until version 8.2, Bind 8 compressed SRV RRs.  There are several ways to 
  handle this:

  1) Refuse to process unknown RR types.  This makes people upset, 
     especially since ipv6 and DNSSEC have created a number of RR records
     that are not in RFC1035 that people want to widely deploy.

  2) Refuse to cache DNS replies with unknown RR types.  If a DNS reply
     uses unknown RR records, simply send the record "as is" to the resolver
     making the query.

  3) Refuse to cache/process non-RFC1035 RRs that use compression.  The 
     problem here is that there is no surefire way to detect compression in a 
     RR with an unknown data type.

  4) Store unknown RRs in the cache "as is", and hope they are following
     section 6.1.3.5 of RFC1123.
 
  5) Install every single version of BIND and other nameservers out there,
     and see what RRs they compress.  This is time-consuming, tedious, and
     error-prone.

