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 <mba...@redhat.com <mailto:mba...@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 <mba...@redhat.com
    <mailto:mba...@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 <mba...@redhat.com
        <mailto:mba...@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@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@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 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@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







-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to