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

[David Dejaeghere]

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

2015-08-20 15:09 GMT+02:00 Martin Basti <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>:
>
>>
>>
>> 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>
>> 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 and change the mname record.
>>>
>>> [root at ns02 ~]# ipa dnszone-add
>>> Zone name: test.be
>>>   Zone name: 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 krb5-self * A; grant
>>> TOKIOGROUP.BE krb5-self * AAAA; grant 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
>>> 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.
>>>   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
>>> Server:         127.0.0.1
>>> Address:        127.0.0.1#53
>>>
>>> test.be
>>>        * origin = ns02.tokiogroup.be <http://ns02.tokiogroup.be>*
>>>         mail addr = 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>
>>> 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/30230a2f/attachment.htm>