Hi Petr,

Yes I understand why this is "not possible". The idea was to have a
managed DNS server from scripting and one for "other usage" by clients
who only need to know about the "unknown" records on Server1, this as
it should forward most and only do specific local lookups.

Your subdomain solution might be something if I want to go this way.

Thanks!

Matt

2015-06-29 15:37 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
> On 29.6.2015 14:07, Matt . wrote:
>> Hi Petr,
>>
>>
>> Bot servers have zone:
>>
>> domain.tld
>>
>> Server1 (192.168.1.1) has:
>>
>> domain.tld
>> foo A 192.168.1.10
>> bar A 192.168.1.20
>>
>>
>> Server2  (192.168.2.1) has:
>>
>> domain.tld
>> candy A 192.168.2.100
>>
>>
>> I have a forward first on Server1 to the IP of Server2
>>
>> So when my DNS server on my client is 192.168.1.1 and I do a nslookup
>> candy.domain.tld it should not lookup locally but on the forward
>> (Server2). But when I lookup foo.domain.tld it should get a reply of
>> Server1
>
> Okay, now I understand it. It is not possible now and it will likely never be
> possible because it breaks the basic principles of DNS.
>
> You are expected to have one set of servers which are authoritative for a
> given zone and this set of servers should synchronized databases among each 
> other.
>
> If you really want to split responsibility for different records to multiple
> servers then you should create sub-domains and do proper delegation for
> sub-domains.
>
> For example, server 1 might be authoritative for zone domain.tld. This domain
> can contain delegation to server2 for names candy.domain.tld and so on.
>
> I hope this helps.
>
> Petr^2 Spacek
>
>
>>
>> rpm -q bind-dyndb-ldap bind ipa-server
>> bind-dyndb-ldap-2.3-6.el6_6.x86_64
>> bind-9.8.2-0.30.rc1.el6_6.3.x86_64
>> ipa-server-3.0.0-42.el6.centos.x86_64
>>
>> It would also be great if this is possible between IPA 3 and 4.
>>
>> Thanks for your help so far!
>>
>> Cheers,
>>
>> Matt
>>
>> 2015-06-29 13:44 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
>>> On 29.6.2015 13:16, Matt . wrote:
>>>> Hi,
>>>>
>>>> The zones are on both servers, just not all records are, this has a
>>>> reason. One server is maintained by a script, the other one only
>>>> forwards to it if needed.
>>>>
>>>> The idea is that it does a local lookup, when it doesn't find the
>>>> record locally, it forwards to it's forwarder to see if it has an
>>>> "answer".
>>>>
>>>> I thought this was working but isn't and following your table it should.
>>>
>>> I'm sorry but I do not understand.
>>>
>>> Could you please give us specific examples?
>>> - what data you have in what zones and on what server
>>> - what is your forwarding configuration
>>> - what is the result you get
>>> - what is the expected result
>>>
>>> Also, please add output from command:
>>> $ rpm -q bind-dyndb-ldap bind ipa-server
>>>
>>> Thanks.
>>>
>>>> What are my options ?
>>> We will see once I understand your requirement :-)
>>>
>>> Petr^2 Spacek
>>>
>>>> 2015-06-29 11:20 GMT+02:00 Petr Spacek <pspa...@redhat.com>:
>>>>> On 27.6.2015 19:06, Matt . wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> When I add a forwarder with policy to forward first, there is only
>>>>>> forwarder and not a fallback to local when the record doesn't exist on
>>>>>> the forward server.
>>>>>>
>>>>>> When I remove the forwardserver, the local lookup works great again.
>>>>>>
>>>>>> Is this known to 3.0 servers or has it been a bug or am I doing somethin 
>>>>>> wrong ?
>>>>>
>>>>> Forwarders in FreeIPA behave in the same way as in BIND 9.9 and the 
>>>>> behavior
>>>>> you describe seems to be okay.
>>>>>
>>>>> The behavior is summarized in a nice table here:
>>>>> http://www.freeipa.org/page/V4/Forward_zones#Use_Cases
>>>>>
>>>>> In other words, there is no thing like 'look into this zone and look into 
>>>>> that
>>>>> zone if the first zone does not contain an answer'. Such behavior would 
>>>>> break
>>>>> the very basic principle of DNS - division to independent, self-contained
>>>>> zones. What are you trying to achieve? What is the use-case?
>>>>>
>>>>> Please note that in FreeIPA < 4.1 zones with non-empty 'forwarders' 
>>>>> attribute
>>>>> were automatically configured as forward zones. The split to pure forward 
>>>>> and
>>>>> master zones happened in FreeIPA 4.1.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to