DNS name pointer

[Chris Thompson]

On Apr 26 2006, Barry Margolin wrote:

>In article <e2m8t1$2fkg$1 at sf1.isc.org>,
> Kevin Darcy <kcd at daimlerchrysler.com> wrote:
>
>> Rohit Tandon wrote:
>> 
>> >Hi All,
>> >
>> >I was wondering if the NAME pointers that are used during compression
>> >of a DNS packet can actually point to another pointer within the DNS
>> >message. Is there any restriction that pointers should point to only
>> >NAME or part of a NAME?
>> >
>> Offhand, I don't see any explicit restriction on that in the RFCs, but 
>> what would be the value of adding the extra level(s) of indirection? I 
>> see only risks, since probably most DNS implementations wouldn't expect 
>> it and might handle it badly, and no benefits.
>
>You're right that there's not much point to pointing directly to another 
>pointer. 

I'm inclined to think that "implementations ... might handle it badly"
is closer to the mark. A decompressor needs a loop stopper, and one
obvious choice is

   1. make sure you only read from inside the (DNS) packet
   2. make sure the expanded name doesn't go over 255 bytes
   3. make sure that a pointer never points directly to another pointer

Without (3) you could be in deep trouble. An alternative which I suspect
may sometimes be used is

   3'. make sure pointers always go backwards

Not that (3) or (3') can be strictly justified by appeal to the RFCs, afaik.

>          However, a variant case is certainly possible where a pointer 
>points to a name that contains another pointer.  E.g. you could have the 
>following names in a packet:
>
>foo.com.
>bar.foo.com.
>x.bar.foo.com.
>
>These could be encoded as
>
>foo.com.
>bar.<pointer to foo.com>
>x.<pointer to bar.foo.com>

Could be, and frequently is.

>The code necessary to handle this would *probably* handle the OP's case 
>properly, since expansion should be a simple recursive process.

Iterative, rather than recursive, surely? You never come back after
following a pointer.

I am not sure about modern BIND code, but at one time the compressor used
to look for any matching byte sequence in the already-constructed part of
the packet. If you happened to have an A record for 2.117.107.0, its rdata
would make a handy representation of (terminal) ".uk" to point to.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk