Feedback on D2 server/domain configuration

[Thomas Markwalder]

On 6/11/13 8:12 AM, Tomek Mrugalski wrote:
> On 10.06.2013 15:25, Thomas Markwalder wrote:
>> Morning gents:
>>
>> I have the bulk of the configuration management support working for D2.
>> I am now at the point where I could use some feedback on how to organize
>> the domain/server information in the configuration set. I'm proposing
>> the following layout which is essentially server-centric.  It maps a
>> list of domains that are supported by a set of forward and reverse servers:
>>
>> DNS Map List
>>      DNS Map<0>
>>          Forward Server List
>>              Server<0> hostname or ip address/port
>>              :
>>              Server<n>
>>          Reverse Server List:
>>              Server<0> hostname or ip address/port
>>              :
>>              Server<n>
>>              Domain Name List:
>>                  Domain Name<0>
>>                  :
>>                  Domain Name<n>
>>      DNS Map<n>
>>
>> So the most basic setup would be a single server (with no backups) that
>> supported all domains:
>>
>> DNS Map<0>
>>      Forward Server<0> 192.168.1.33,4500
>>      Reverse Server<0> 192.168.1.33,4500
>>      Domain Name<0> "*"
> Do we need to have port specified separately? I thought the DNS traffic
> always goes over port 53. The only case when we could use different port
> would be for testing purposes and even that *sending* to privileged port
> does not require root privileges.
>
> Do we want to separate forward and reverse servers? Perhaps it would be
> easier if instead of port number, you could specify a role (fwd, rev,
> both). Then the simplest configuration be:
>
> DNS Map<0>
>      DNS Server<0> 192.168.1.33,both
>      Domain Name<0> "*"
>
> On the other hand, this simplicity would be paid by more complex
> handling of the DNS Server list. I don't say we should do it, it's just
> something we may consider.
>
> But I don't have clear understanding of how the complex stuff could be
> configured. Forward Server entries denote DNS servers, sorted from the
> most to least preferred DNS servers for all domains specified on Domain
> Name, right? How would that configuration look if I wanted to say:
>
> domain1.example.org should be updated to 192.1.1.1
> domain2.example.org should be updated to 192.1.1.2
> domain2.example.org should be updated to 192.1.1.3
> reverse for all domains should be updated to 192.1.1.4
>
> Would I have to repeat the reverse configuration for each domain?
>
>
At Stephen's suggestion I looked over how BIND9 handles the 
configuration, and it is zone or domain centric rather than server 
centric.   Below is a configuration layout, with that information in 
mind.  Note it also addes TSIG key information, which the prior layout 
more or less ignored.

The overall structure of the configuration would be this:

# List of TSIG keys used by one or more domains
KeyList
     Key<0>
     :
     Key<n>

# List of all of the forward domains
ForwardDomainList
     domain<0>
     :
     domain<n>

# List of all of the reverse domains
ReverseDomainList
     domain<0>
     :
     domain<n>


# Each TSIG_Key is comprised of the following:
TSIG_Key
{
     name
     algorithm
     secret
}

# Each domain is comprised of the following:
DdnsDomain
{
     domain_name
     key_name
     server_list
     {
         hostname or ip address,
         hostname or ip address
     }
}

Using Tomek's earlier example of:

     domain1.example.org should be updated to 192.1.1.1
     domain2.example.org should be updated to 192.1.1.2
     domain2.example.org should be updated to 192.1.1.3
     reverse for all domains should be updated to 192.1.1.4

and add to that, suppose they all use the same TSIG_key,
then the configuration would look something like this:


KeyList
{
     Key<0>
     {
         name : d2.example.org
         algorithm : hmac-md5
         secret : RxOu1NWXSpvNqfP8rm6Q===
     }
}

Forward Domain List
{
     Domain<0>
     {
         name domain1.example.org
         key  d2.example.org
         Server List
         {
             server<0> 192.168.1.1
         }
     }
     Domain<1>
     {
         name domain2.example.org
         key  d2.example.org
         Server List
         {
             server<0> 192.168.1.2
         }
     }
     Domain<2>
     {
         name : domain1.example.org
         key  : d2.example.org
         Server List
         {
             server<0> 192.168.1.3
         }
     }
}


Reverse Domain List
{
     Domain<0>
     {
         name : example.org"
         key :  d2.example.org
         Server List
             server<0> 192.168.1.4
     }
}

Stephen had suggested a hierarchical arrangement:

     Domain myhosting.com
        servers: name/ip, name/ip
        subdomains:
           Domain: morris.myhosting.com
               servers: name/ip, name/ip
           Domain: markwalder.myhosting.com
               servers: name/ip, name/ip

but I'm not sure I see any particular advantage to allowing them to nest 
in the configuration.
Specifying in a flat arrangement seems simpler:

     Domain myhosting.com
        servers: name/ip, name/ip
     Domain: morris.myhosting.com
         servers: name/ip, name/ip
     Domain: markwalder.myhosting.com
         servers: name/ip, name/ip

One could easily adjust the proposed scheme above to accommodate 
hierarchy by adding
a "Subdomain List" to the domain definition.