[Freeipa-devel] [Freeipa-users] Dns SOA MNAME not resolving from LDAP data

[Martin Basti]

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-devel/attachments/20150820/ddc0a5e8/attachment.htm>