Maximum number of updates in a single transaction

Kevin Darcy kcd at daimlerchrysler.com
Sat Feb 11 01:29:49 UTC 2006


Mark Andrews wrote:

>>Mark Andrews wrote:
>>
>>    
>>
>>>>Hi,
>>>>
>>>>We are implementing a new service that requires a substantial number 
>>>>of dynamic updates to be performed on a zone. We are talking of 2K 
>>>>updates in a single dynamic update transaction.
>>>>
>>>>We made some tests with Bind 9.3.2 by sending 60 domain updates in a 
>>>>single transaction (TCP) and everything works correctly.
>>>>
>>>>RFC2136 specify a 16 bit limit to UPCOUNT section in the header, so I 
>>>>assume that the limit of updates that I can send on a single 
>>>>transaction is 2^16.
>>>>
>>>>What is your recommendation of the maximum number of updates in a 
>>>>single transaction?
>>>>
>>>>I believe that ISC makes validation tests with each BIND release. How 
>>>>many dynamic updates are sent in the ISC's validation tests?
>>>>
>>>>Thank you.
>>>>
>>>>
>>>>
>>>>Gustavo Lozano
>>>>NIC Mexico (ccTLD .mx)
>>>>   
>>>>
>>>>        
>>>>
>>>	The limitation is the size of the DNS message.  A individual
>>>	message can be up to 65535 bytes.
>>>
>>>      
>>>
>>Right, which implies that the real-world limit on number of updates in a 
>>transaction is going to be far less than 65535 (since each update takes 
>>at least several bytes), and is going to depend on a number of factors, 
>>such as: whether and/or how many prerequisites there are, the length of 
>>the names/RDATAs involved, the extent of label compression, etc.
>>
>>One question that comes to my mind is: does BIND support sending 
>>multiple UPDATE transactions over the same TCP connection? Seems like 
>>there is nothing to forbid this in the RFCs and the precedent has 
>>already been set in the case of AXFR...
>>    
>>
>
>	Actually there is.  Updates are atomic.  You can't sent two
>	updates and have a atomic transaction.
> 
>  
>
True, they would be treated as separate transactions, and wouldn't be 
atomic with respect to each other. But with that caveat understood by 
the generating application, sending both updates on the same TCP 
connection might derive some slight amount of efficiency, especially if 
each of them is so large that TCP is mandatory anyway. Why set up and 
tear down two TCP connections, when one will suffice?

                                                                         
                                                      - Kevin




More information about the bind-users mailing list