MacOS 9 Dynamic DNS Update

[Barry Margolin]

In article <200001171734.LAA06905 at achilles.ctd.anl.gov>,
Barry Finkel  <b19141 at achilles.ctd.anl.gov> wrote:
>>>Barry Finkel  <b19141 at achilles.ctd.anl.gov> wrote:
>> Barry Margolin's Reply:
>  My reply 
>
>>>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.

>Another question - There are two TXT records being sent in update packets.
>Will BIND add both to the DNS zone (assuming that the DNS allows such updates)?
>Or will the second one replace the first one?

It will add them both.  A name can have as many entries with the same type;
consider round-robin A records, multiple MX records, all the NS records,
etc.

-- 
Barry Margolin, barmar at bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.