dhcpd ddns request 1 sec timeout

[Simon Hobson]

Seiji T wrote:

>  > The dhcp server is single threaded, so it blocks while the dns update
>>  is done. If it waits too long it may miss other incoming dhcp requests.
>
>I understand that but then, why is 1 sec okay and not 2 sec? Why not 500 msec?

Design decision taken when the system was written ? I believe the 
internal timer only works in whole seconds, so the minimum timeout is 
1s.

>  > If your incoming dhcp rate is pretty low then there should be little
>>  harm in bumping the timeout up to two seconds. But really you should
>>  look at your DNS infrastructure and see if there is a way to improve
>>  it's response.
>
>Maximum possible rate will be like 7000 DHCP requests at once to 2
>dhcp servers.

I think you need to qualify that. What does 'at once' really mean, 
because if they all come in one second then they aren't going to get 
serviced ! I assume you are thinking in terms of "we have 7000 
clients and if there's a wide area power cut then they'll all come up 
at once". Firstly, how likely (or how often) is such an event, and 
secondly, unless all the equipment is identical AND powers up 
automatically, then there will be a spread of time. I would imagine 
that the rate will follow something resembling a bell curve.

If you had the worst case where every client caused a dns update, and 
they all failed or went close to the timeout, then a 1s timeout would 
limit you to 3600 clients/hour - or about 2 hours to service all your 
7000 clients. In practice, only a small percentage of client updates 
should result in a dns update - if say 10% did, then the dns timeout 
itself would impose a limit of more like 36,000/hour or about 12 
minutes to service your 7000 clients.

This is one area you do have control over. If you set (say) 2 week 
leases then you would need a wide area outage of at least a week 
before you have a significant number of leases timing out - by that 
time, taking a couple of hours to get all the clients back up is not 
likely to be top of everyones list of issues !

>As you have suggested, we are planning to change our DNS
>infrastructure. Currently the DDNS server transfers full zone data to
>approx 20 secondary servers everytime DNS database changes.

That sounds like a bad dns design ! Why do you need so many servers ? 
Even ISPs with several hundreds of thousands of clients tend to only 
have 2-4 dns servers.

>We are thinking of relaying via a hub server which will then 
>transfer the full zone data to the 20-something secondary servers. 
>We thought of incremental zone transfer but we never done it before 
>and decided that relaying to one server is safer.

What software are you using ?

Incremental transfers will reduce the amount of traffic and probably 
reduce the time taken, it's low risk and common packages (like bind) 
'just do it' automatically. Also, you could consider NOT notifying 
the secondary servers and let them poll the master every few minutes.

I was under the impression that bind will rate-limit the number of 
zone updates it does when there's a lot of updates, though I don't 
recall any details.

>We are looking at other options and the purpose of this thread is to
>understand the rationale behind the 1 sec fix.

My guess would be that when this bit was written, the developers were 
using bind for the dns and didn't have any problems with a 1s 
timeout. Given that the dhcp server blocks while it's waiting, the 
minumum is 1s, and there didn't seem to be any need to make it longer 
- it just got set at 1s.

Beyond that, there's no magic in the 1s value !


It might help if you describe your setup and what you think your 
problems are - ie the bigger picture. Chances are it's not too 
different to what others have already done in the past and can give 
helpful advice.