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,


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.


2015-08-20 14:38 GMT+02:00 Martin Basti <mba...@redhat.com <mailto:mba...@redhat.com>>:

    On 08/20/2015 02:35 PM, David Dejaeghere wrote:

    Correct. But i never set this. This option seems to be set by
    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,

    (Adding freeipa-users back)

    I checked code, it is default.

    You can change named.conf, upgrade will not replace it.


    2015-08-20 14:32 GMT+02:00 Martin Basti <mba...@redhat.com

        On 08/20/2015 02:22 PM, Martin Basti wrote:

        On 08/20/2015 01:48 PM, David Dejaeghere wrote:

        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@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
          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 *
          Dynamic update: FALSE
          Allow query: any;
          Allow transfer: none;
        [root@ns02 ~]# ipa dnszone-mod --nameserver
        anaconda-ks.cfg .bash_logout .bashrc .ipa/            .ssh/
        .bash_history .bash_profile .cshrc .pki/            .tcshrc

        [root@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
        NS record(s) can be edited in zone apex - '@'.
          Zone name: test.be <http://test.be>.
          Active zone: TRUE
        *Authoritative nameserver: 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@ns02 ~]# nslookup
        > set q=SOA
        > test.be <http://test.be>

        test.be <http://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


        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.


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to