[Freeipa-users] Forward first not working
Martin Basti
mbasti at redhat.com
Wed Feb 25 18:18:49 UTC 2015
On 25/02/15 18:51, Shaun Martin wrote:
> Hi Martin,
>
> The zone name is the following for both servers.
>
> Zone name:
> 1.10.in-addr.arpa.
>
>
> I am using zone forwarders.
>
> With forward first enabled though it should try and return an answer
> from the local DNS, it clearly does not though. The only time I
> receive the local record is when forwarding is disabled.
>
> Thanks,
> Shaun
>
>
> Shaun Martin
> IT\OPS Manager
> Black Duck Software
> O: +1.781.425.4336
>
> Black Duck Software <http://www.blackducksoftware.com/> | OpenHUB
> <https://www.openhub.net/> | OSDelivers
> <http://osdelivers.blackducksoftware.com/> | OSS Logistics
> <https://www.blackducksoftware.com/oss-logistics>
>
> <http://twitter.com/black_duck_sw><https://www.linkedin.com/company/black-duck-software><https://www.facebook.com/BlackDuckSoftware><https://plus.google.com/+Blackducksoftware/><http://www.slideshare.net/blackducksoftware>
>
> /JP Morgan Chase & Co. Hall of Innovation Inductee/
> <https://www.youtube.com/user/BlackDuckSoftware>
>
> On Feb 25, 2015, at 12:42 PM, Martin Basti <mbasti at redhat.com
> <mailto:mbasti at redhat.com>> wrote:
>
>> On 25/02/15 17:59, Shaun Martin wrote:
>>> Hi,
>>>
>>> I am having an issue with the forward first not appear to be
>>> working. I have two separate IPA servers that server separate
>>> realms. I have for the reverse zone configured forwarders to point
>>> to the other realms IPA server. All versions are identical on the
>>> IPA servers. I have included details on version and tests that show
>>> this is not working.
>>>
>>> $ yum list installed |grep bind-dyndb-ldap
>>> bind-dyndb-ldap.x86_64 3.5-4.el7
>>> @base
>>>
>>> $ yum list installed |grep ipa
>>> ipa-admintools.x86_64 3.3.3-28.0.1.el7.centos.3 @updates
>>> ipa-client.x86_64 3.3.3-28.0.1.el7.centos.3 @updates
>>> ipa-python.x86_64 3.3.3-28.0.1.el7.centos.3 @updates
>>> ipa-server.x86_64 3.3.3-28.0.1.el7.centos.3 @updates
>>> libipa_hbac.x86_64 1.11.2-68.el7_0.6 @updates
>>> libipa_hbac-python.x86_64 1.11.2-68.el7_0.6 @updates
>>> python-iniparse.noarch 0.4-9.el7
>>> @anaconda
>>> sssd-ipa.x86_64
>>>
>>> *BELOW IS WITH FORWARDING DISABLED*. It cannot find 10.1.0.9 but can
>>> find 10.1.20.9. This is expected as this server only has the
>>> 10.1.20.9 record.
>>> $ nslookup
>>> > server 10.1.20.9
>>> Default server: 10.1.20.9
>>> Address: 10.1.20.9#53
>>> > 10.1.20.9
>>> Server:10.1.20.9
>>> Address:10.1.20.9#53
>>>
>>> 9.20.1.10.in-addr.arpaname = prd-ops-ipa01.uzb.local.
>>> > 10.1.0.9
>>> Server:10.1.20.9
>>> Address:10.1.20.9#53
>>>
>>> ** server can't find 9.0.1.10.in-addr.arpa.: NXDOMAIN
>>>
>>> *BELOW IS WITH FORWARDING ENABLED*. It cannot find 10.1.20.9 but can
>>> find 10.1.0.9. This is expected as the forwarding server only has
>>> the 10.1.0.9 record.
>>> > 10.1.20.9
>>> Server:10.1.20.9
>>> Address:10.1.20.9#53
>>>
>>> ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN
>>> > 10.1.0.9
>>> Server:10.1.20.9
>>> Address:10.1.20.9#53
>>>
>>> Non-authoritative answer:
>>> 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local.
>>>
>>> Authoritative answers can be found from:
>>> 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local.
>>>
>>>
>>> *BELOW IS WITH FORWARD FIRST ENABLED*. It cannot find 10.1.20.9 but
>>> can find 10.1.0.9. This is un-expected as the local zone has the
>>> 10.1.20.9 and the forward server has the 10.1.0.9 so we should be
>>> getting both.
>>> > 10.1.20.9
>>> Server:10.1.20.9
>>> Address:10.1.20.9#53
>>>
>>> ** server can't find 9.20.1.10.in-addr.arpa.: NXDOMAIN
>>> > 10.1.0.9
>>> Server:10.1.20.9
>>> Address:10.1.20.9#53
>>>
>>> Non-authoritative answer:
>>> 9.0.1.10.in-addr.arpaname = ops-ipa01.bbf.local.
>>>
>>> Authoritative answers can be found from:
>>> 1.10.in-addr.arpanameserver = ops-ipa01.bbf.local.
>>> ops-ipa01.bbf.localinternet address = 10.1.0.9
>>>
>>>
>>> Any help is greatly appreciated.
>>>
>>> Thanks,
>>> Shaun
>>>
>>> <Mail Attachment.png>
>>> Shaun Martin
>>> IT\OPS Manager
>>> Black Duck Software
>>> O: +1.781.425.4336
>>>
>>> Black Duck Software <http://www.blackducksoftware.com/> | OpenHUB
>>> <https://www.openhub.net/> | OSDelivers
>>> <http://osdelivers.blackducksoftware.com/> | OSS Logistics
>>> <https://www.blackducksoftware.com/oss-logistics>
>>>
>>> <Mail Attachment.png><http://twitter.com/black_duck_sw><Mail
>>> Attachment.png><https://www.linkedin.com/company/black-duck-software><Mail
>>> Attachment.png><https://www.facebook.com/BlackDuckSoftware><Mail
>>> Attachment.png><https://plus.google.com/+Blackducksoftware/><Mail
>>> Attachment.png><http://www.slideshare.net/blackducksoftware><Mail
>>> Attachment.png>
>>>
>>> /JP Morgan Chase & Co. Hall of Innovation Inductee/
>>> <https://www.youtube.com/user/BlackDuckSoftware>
>>>
>>>
>>>
>> Hello,
>>
>> we need more info:
>> do you use global forwarders, or zone forwarders?
>> how your reverse zones are configured (name, delegation)?
>>
>> Default forwarding policy is first, IMO both of your examples with
>> forwarding enabled are forwarding first policy.
>>
>> Martin
>>
>> --
>> Martin Basti
>
You issue is, the IPA < 4.1, separate zones in following way:
* zone with forwarders specified == forward zone, records inside are ignored
* zone without forwarders, or zone with --forward-policy=none == master
zone, no forwarding
So if you specify forwarders, your zone works as BIND's forward zone
without records.
And I'm not sure if forwarding between 2 authoritative zones with the
same name will work, because the zone is authoritative on IPA side, so
IPA will return authoritative answer NXDOMAIN and will not try to
forward query.
You may need NS delegation to subzone.
I suggest to create separate zones, there should not be 2 authoritative
servers with the same zone.
FYI: Forward zones IPA 4.1: http://www.freeipa.org/page/V4/Forward_zones
HTH
Martin
--
Martin Basti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 3790 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 280 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 248 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 227 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 335 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 355 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 316 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150225/8ceb0cf2/attachment-0006.png>
More information about the Freeipa-users
mailing list