MacOS 9 Dynamic DNS Update

Barry Finkel b19141 at achilles.ctd.anl.gov
Mon Jan 17 17:34:45 UTC 2000


>>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.

--------------------------------------------------------
>>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.
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'

--------------------------------------------------------

>>5) dns0->cmt Port 49158 unreachable
>
>What's prompting these unreachables?  They should only be sent in response
>to cmt sending packets to these ports on dns0 -- did you leave those out of
>your trace?

>>We normally do not have TXT records in our DNS zones; I am not sure
>>why MacOS 9 is trying to add these TXT strings to DNS.
>
>afp is Appleshare Filing Protocol -- it looks to me like MacOS uses Dynamic
>DNS to register availability of servers.  It seems like it's trying to
>emulate what happens on Appletalk networks using Apple's proprietary
>protocols.  This is essentially the same direction that Microsoft is moving
>in for NetBIOS, except that they're using SRV records.
>
>>Note that the responses from dns0 back to cmt are not deliverable,
>>as the destination port is unreachable.
>
>That's not what those packets say.  They say that cmt sent something to an
>unused port on dns0.  Or did you get the direction backwards?
>
>If you got the direction wrong, it's possible that cmt doesn't bother
>waiting for responses to its dynamic updates.  If it's going to ignore an
>error response (most sites don't use dynamic DNS, so it would be ridiculous
>for every Mac to start putting up alerts when it fails), there's no point
>in listening for it.  Since cmt isn't listening on the reply port, it sends
>a port unreachable, which dns0 will ignore.

I had misread the trace records; all five of the records have a source
of cmt and a destination of dns0.

I will read the PDF file in the Apple URL that was supplied by another poster
to see if that documentation explains what the TXT records are.

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?
----------------------------------------------------------------------
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




More information about the bind-users mailing list