DDNS - Question of best practices.

Chris Buxton cbuxton at menandmice.com
Wed Jun 4 17:45:50 UTC 2008


Additionally, I should point out that it's a really good idea to  
separate the DHCP-managed data from your other data, into separate  
zones. That way, a student's laptop can't accidentally overwrite the  
address of your mail server (for example).

Chris Buxton
Professional Services
Men & Mice

On Jun 4, 2008, at 10:29 AM, John Hascall wrote:

>
>
> One thing which may be worth stating explicitly is that
> master-vs-slave is a per-zone concept.  If you can separate
> them into their own zone, you can master your student dns
> names on a system other than where you master your dns names.
>
> John
>
>> The only way that would work is if the "supervisory slave" were
>> actually master for the zone being dynamically updated. It could  
>> still
>> be slave for all static data.
>>
>> Remember, a zone is identical between master and slaves. (The format
>> on disk might be different, but the servers will have the same data  
>> in
>> memory.) There is no way for the slaves to have a different version  
>> of
>> the zone. Therefore, if the "garbage" is part of the zone, then the
>> primary master for that zone must have it.
>>
>> As a corollary, slaves cannot process dynamic updates other than to
>> forward them upstream, in the direction of the primary master.
>>
>> Is there some reason you don't want your hidden master to contain the
>> data about student workstations?
>>
>> Chris Buxton
>> Professional Services
>> Men & Mice
>>
>> On Jun 4, 2008, at 10:01 AM, Luis Fernando Lacayo wrote:
>>
>>> Chris,
>>>
>>> Thanks for the reply.  My concern is that a hidden master  
>>> shouldn't be
>>> touch but for the slaves...
>>>
>>> So I was thinking that the DHCP servers would talk to with what I
>>> consider a supervisory slave, and he would distribute down to the
>>> slaves. The Hidden Master does not need to have garbage about the
>>> students work station, does it?
>>>
>>> So I was thinking that having the supervisory slave would be updated
>>> by
>>> the DHCP servers, and he would push the info to the other 3 slaves.
>>>
>>> What are your thoughts.
>>>
>>> Thanks,
>>>
>>> Luis
>>> On Wed, 2008-06-04 at 09:47 -0700, Chris Buxton wrote:
>>>> Dynamic updates must be processed by the primary master server  
>>>> (your
>>>> new hidden master, in this case). However, it's possible to set the
>>>> slaves to forward updates to the master, so that the DHCP server  
>>>> can
>>>> send updates to the local slave.
>>>>
>>>> So, to answer your question, either way will work.
>>>>
>>>> Chris Buxton
>>>> Professional Services
>>>> Men & Mice
>>>>
>>>> On Jun 4, 2008, at 6:45 AM, Luis Fernando Lacayo wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> First let me state that I am pretty new to DDNS and I am looking
>>>>> for a
>>>>> best practice of implementing DDNS.
>>>>>
>>>>> I have a pretty large network, and I am looking to enable DDNS at
>>>>> all
>>>>> the schools as well as the central office of the Chicago Public
>>>>> School
>>>>> system.
>>>>>
>>>>> The following scenario best describes my network right now.
>>>>>
>>>>> I have:
>>>>>
>>>>> 1 master DNS server
>>>>> 3 slave DNS servers
>>>>>
>>>>> The schools use 2 of the the slaves and the central office use the
>>>>> master and the other slave. Right now all the slaves are updated  
>>>>> by
>>>>> the
>>>>> single master.
>>>>>
>>>>> My plan is to implement a HIDDEN master, which will update the  
>>>>> other
>>>>> 4.
>>>>>
>>>>> This is where I am a little unsure.
>>>>>
>>>>> Should the DHCP server update the hidden master via DDNS or  
>>>>> should I
>>>>> update the other 4 directly.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Luis
>>>>> -- 
>>>>> Luis Fernando Lacayo
>>>>> Chicago Public Schools
>>>>> Senior Unix Administrator
>>>>> ITS/ UNIX Infrastructure
>>>>> Office: 773-553-3835
>>>>> Cell: 773-203-4493
>>>>>
>>>>>
>>>>
>>> -- 
>>> Luis Fernando Lacayo
>>> Chicago Public Schools
>>> Senior Unix Administrator
>>> ITS/ UNIX Infrastructure
>>> Office: 773-553-3835
>>> Cell: 773-203-4493
>>>
>>>
>>
>>
>
>



More information about the bind-users mailing list