MacOS 9 Dynamic DNS Update

[Barry Finkel]

>>>>Barry Finkel  <b19141 at achilles.ctd.anl.gov> wrote:
>>> Barry Margolin's Reply:
>>  My reply 
>   Barry Margolin's Reply:
    All of my latest reply text is at the end of the posting.

>>>>The topic of MacOS 9 dynamic DNS update was raised earlier this week.
>>>>I have decoded some dynamic DNS traffic between a MacOS 9 system and one
>>>>of our DNS machines.  The MacOS 9 system is
>>>>
>>>>     146.139.224.239 [dhcp-4-239.cmt.anl.gov]
>>>>
>>>>There were five records in the sniffer trace.
>>>>
>>>>1) cmt->dns0 ICMP Echo
>>>>2) cmt->dns0 Register -- In the cmt.anl.gov domain, for entry dhcp-4-239, 
>>>>             add a TXT record with the following text of length 24:
>>>>                   <ETB>swip://146.139.224.239/
>>>>
>>>>             Note that the first character is X'17' (End of
>>Transmission Block).
>>>
>>>Hmm, that's the exact length of the text without the ETB character.
>>
>>I count 24 characters -- <ETB> is #1; the trailing "/" is #24.
>
>Like I said: "without the ETB character".  That's 23, which is 17 in hex.
>
>>--------------------------------------------------------
>>>>3) dns0->cmt Port 49155 unreachable
>>>>4) cmt->dns0 Register -- In the cmt.anl.gov domain, for entry dhcp-4-239, 
>>>>             add a TXT record with the following text of length 61:
>>>>                  
>>=<afp://146.139.224.239/?NAME=Conner_PPC_G3_300&ZONE=CMT%20205
>>>
>>>Actually, the length of that text is 62.  But it's 61 if you don't include
>>>the initial '=' character, whose ASCII code just happens to be 61.  Are you
>>>sure your DNS decoder is correct -- it looks like it's displaying the
>>>length byte as part of the text (although it's conceivable that MacOS is
>>>setting the text data to a counted string for some reason).
>>
>>I count 62 characters -- "=" is #1; the trailing "5" is #62.
>
>That's what I said.  You wrote "of length 61" above.
>
>>The sniffer produces a hex dump of the records; I manually decode the hex data
>>to determine what are the fields in the DNS records.  My decoding might have
>>errors.  Here is my decoding of part of record 4):
>>
>>0050                                                00  U1TYPE =
>>0060  10                                                         16 = TXT
>>0060     00 01                                          U1CLASS = 1 = IN
>>0060           00 00 0E 10                              U1TTL = X'E10' = 3600
>>0060                       00  3D                       U1RDLENGTH =
>>X'3D' = F'61'
>>0060                              3C 61 66 70 3A 2F 2F  U1RDATA '=<afp://
>>0070  31 34 36 2E 31 33 39 2E  32 32 34 2E 32 33 39 2F    146.139.224.239/
>>0080  3F 4E 41 4D 45 3D 43 6F  6E 6E 65 72 5F 50 50 43    ?NAME=Conner_PPC
>>0090  5F 47 33 5F 33 30 30 26  5A 4F 4E 45 3D 43 4D 54    _G3_300&ZONE=CMT
>>00A0  25 32 30 32 30 35                                   %20205'
>
>Looks to me like a bug in the sniffer.  The hex line corresponding to the
>U1RDATA begins with 3C, which is the ASCII code for '<'.  It seems to be
>dragging in the 2nd byte of the U1RDLENGTH (3D) and putting it at the
>beginning of the U1RDATA.

I have come to the conclusion that what MacOS 9 is doing is this:
The first byte in the URDATA field in the Update Zone denotes the
length of the RDATA string that follows.  So, in the two update records,

     U1RDLENGTH = F'24' = X'18', and U1RDATA[0] = F'23' = X'17' = <ETB>
     U1RDLENGTH = F'61' = X'3D', and U1RDATA[0] = F'60' = X'3C' = "<"

And I realized that I should not have included the "=" as part of the
string in the U1RDATA line.  That manual formatting was mine from the 
raw hex records.
----------------------------------------------------------------------
Barry S. Finkel
Electronics and Computing Technologies Division
Argonne National Laboratory          Phone:    +1 (630) 252-7277
9700 South Cass Avenue               Facsimile:+1 (630) 252-9689
Building 221, Room B236              Internet: BSFinkel at anl.gov
Argonne, IL   60439-4844             IBMMAIL:  I1004994