[Freeipa-users] Dns SOA MNAME not resolving from LDAP data
Martin Basti
mbasti at redhat.com
Thu Aug 20 15:32:37 UTC 2015
On 08/20/2015 03:14 PM, David Dejaeghere wrote:
> The reason I hit this issue was because I am testing out a setup where
> ldap etc are running on a private subnet but is hosting public zones.
> Therefor I change the nameservers of these zones and the primary
> nameserver soa record to a public reachable hostname.
>
> I agree this is no issue for the majority of users.
>
> There already is a warning in the UI and IPA CLI. It might be good to
> add an extra line to this warning regarding the fake_mname, altought
> this might also cause confusion.
>
> Regards,
>
> David
I agree, ticket filed: https://fedorahosted.org/freeipa/ticket/5241
>
> 2015-08-20 15:09 GMT+02:00 Martin Basti <mbasti at redhat.com
> <mailto:mbasti at redhat.com>>:
>
>
>
> On 08/20/2015 02:46 PM, David Dejaeghere wrote:
>> confirmed working.
>> Does this default value make any sense if this value is
>> changeable in the UI and using the IPA client?
>>
>> Kind Regards,
>>
>> David
>
> IMHO (I'm not 100% sure)
>
> IPA DNS are master servers, which contains only authoritative zones.
> Each DNS server contains the same copy of zones synchronized with
> LDAP database, and each server is authoritative for that zone
> (multimaster DNS topology).
> So there is no reason to have listed different server than IPA DNS
> as authoritative servers.
>
> This works for majority users.
>
> This also works as fallback (on local network only without
> caching) when one replica is down, the one of IPA DNS servers
> left, may act as authoritative servers (primary master for DDNS).
>
> I agree that this is tricky (I forgot about fake_mname too) for
> users who want to change it, we may show warning for user or
> somehow let him know that fake_mname is used.
>
> Martin
>
>>
>> 2015-08-20 14:38 GMT+02:00 Martin Basti <mbasti at redhat.com
>> <mailto:mbasti at redhat.com>>:
>>
>>
>>
>> On 08/20/2015 02:35 PM, David Dejaeghere wrote:
>>> Aha,
>>>
>>> Correct. But i never set this. This option seems to be set
>>> by default.
>>> I verified this issue on multiple installs. It seems they
>>> all have this option set by default?
>>>
>>> Can i safely change named.conf without fearing my
>>> modifications will be lost on an update?
>>>
>>> Kind Regards,
>>>
>>> David
>> (Adding freeipa-users back)
>>
>> I checked code, it is default.
>>
>> You can change named.conf, upgrade will not replace it.
>>
>> Martin
>>
>>>
>>> 2015-08-20 14:32 GMT+02:00 Martin Basti <mbasti at redhat.com
>>> <mailto:mbasti at redhat.com>>:
>>>
>>>
>>> On 08/20/2015 02:22 PM, Martin Basti wrote:
>>>>
>>>>
>>>> On 08/20/2015 01:48 PM, David Dejaeghere wrote:
>>>>> Hi,
>>>>>
>>>>> I noticed that changing the authoritarive nameserver
>>>>> in FreeIPA reflects correctly to its directory data
>>>>> but bind will not resolve the soa record with the
>>>>> updated mname details.
>>>>>
>>>>> For example I add a zone test.be <http://test.be> and
>>>>> change the mname record.
>>>>>
>>>>> [root at ns02 ~]# ipa dnszone-add
>>>>> Zone name: test.be <http://test.be>
>>>>> Zone name: test.be <http://test.be>.
>>>>> Active zone: TRUE
>>>>> *Authoritative nameserver: ns02.tokiogroup.be
>>>>> <http://ns02.tokiogroup.be>.*
>>>>> Administrator e-mail address: hostmaster
>>>>> SOA serial: 1440070999
>>>>> SOA refresh: 3600
>>>>> SOA retry: 900
>>>>> SOA expire: 1209600
>>>>> SOA minimum: 3600
>>>>> BIND update policy: grant TOKIOGROUP.BE
>>>>> <http://TOKIOGROUP.BE> krb5-self * A; grant
>>>>> TOKIOGROUP.BE <http://TOKIOGROUP.BE> krb5-self * AAAA;
>>>>> grant TOKIOGROUP.BE <http://TOKIOGROUP.BE> krb5-self *
>>>>> SSHFP;
>>>>> Dynamic update: FALSE
>>>>> Allow query: any;
>>>>> Allow transfer: none;
>>>>> [root at ns02 ~]# ipa dnszone-mod --nameserver
>>>>> anaconda-ks.cfg .bash_logout .bashrc .ipa/ .ssh/
>>>>> .bash_history .bash_profile .cshrc .pki/ .tcshrc
>>>>>
>>>>>
>>>>> [root at ns02 ~]# ipa dnszone-mod
>>>>> --name-server*ns7.tokiogroup.be
>>>>> <http://ns7.tokiogroup.be>*.
>>>>> Zone name: test.be <http://test.be>
>>>>> ipa: WARNING: Semantic of setting Authoritative
>>>>> nameserver was changed. It is used only for setting
>>>>> the SOA MNAME attribute.
>>>>> NS record(s) can be edited in zone apex - '@'.
>>>>> Zone name: test.be <http://test.be>.
>>>>> Active zone: TRUE
>>>>> *Authoritative nameserver: ns7.tokiogroup.be
>>>>> <http://ns7.tokiogroup.be>.*
>>>>> Administrator e-mail address: hostmaster
>>>>> SOA serial: 1440071001
>>>>> SOA refresh: 3600
>>>>> SOA retry: 900
>>>>> SOA expire: 1209600
>>>>> SOA minimum: 3600
>>>>> Allow query: any;
>>>>> Allow transfer: none;
>>>>>
>>>>>
>>>>> [root at ns02 ~]# nslookup
>>>>> > set q=SOA
>>>>> > test.be <http://test.be>
>>>>> Server: 127.0.0.1
>>>>> Address: 127.0.0.1#53
>>>>>
>>>>> test.be <http://test.be>
>>>>> *origin = ns02.tokiogroup.be <http://ns02.tokiogroup.be>*
>>>>> mail addr = hostmaster.test.be
>>>>> <http://hostmaster.test.be>
>>>>> serial = 1440071001
>>>>> refresh = 3600
>>>>> retry = 900
>>>>> expire = 1209600
>>>>> minimum = 3600
>>>>>
>>>>> As you can see the SOA record still shows the original
>>>>> default value.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> David Dejaeghere
>>>>>
>>>>>
>>>>
>>>> Thank you for this bug report.
>>>> I opened bind-dyndb-ldap ticket
>>>> https://fedorahosted.org/bind-dyndb-ldap/ticket/159
>>>>
>>>> Martin
>>>>
>>>>
>>> I maybe found why do you have this issue,
>>>
>>> do you have fake_mname configured in bind_dyndb_ldap
>>> section of named.conf?
>>> If yes then remove this option to use SOA MNAME from LDAP.
>>>
>>> Martin
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20150820/62a4d60f/attachment.htm>
More information about the Freeipa-users
mailing list