Viktor,
On 24/10/2018 11.01, Viktor Dukhovni wrote:
My reading of RFC 1035 is that DNS name "compression"
via "pointers" is restricted to name strictly earlier
in the DNS message:
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the end of a domain name is replaced with a pointer to a prior occurance
---------------
of the same name.
And yet, here and there I see mention of having to take care to avoid "loops",
but loops are impossible in a monotone strictly decreasing sequence.
I think the concern is something like this:
offset octet
100 3
101 'f'
102 'o'
103 'o'
104 192
105 100
104 and 105 together point to offset 100, which will cause a loop even
though they point to an earlier label.
Is there a later RFC that relaxes the constraint and allows pointers to names
later in the message? I'm having a bit of trouble finding the later text...
Secondarily, can the pointer point to some odd-ball location earlier in the
message that is not semantically a label in its original context, but just
happens to carry data that decodes as the desired label? Or, are pointers
only valid to prior locations that are corresponding labels in their original
context?
I have seen code which does this (there was an early version of the Knot
authoritative server which used non-label offsets if it happened to have
the correct data). Certainly it is easily possible that RDATA contains
valid labels which could be used to by compression.
I think that for performance reasons most DNS software producing packets
will maintain some data structure of prior labels & names in a packet
and only reference those in compression. However, anything consuming DNS
packets should probably be prepared for arbitrary pointers to previous
locations in the packet - and also handle loops somehow (the usual
options apply: either explicitly recording locations visited in
traversal or just maintaining a counter and failing at some point).
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
