Slave fails failover - DNS

This is a discussion on Slave fails failover - DNS ; Hello, as commonly done, I have two DNS servers for a domain, that is, the toplevel zone at the hoster is $ORIGIN xyz.com. jen IN NS dns1.foo.com. (running ISC BIND 9.3.2) jen IN NS dns2.bar.com. (also ISC BIND 9.3.2) $ORIGIN ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Slave fails failover

  1. Slave fails failover

    Hello,


    as commonly done, I have two DNS servers for a domain, that is, the
    toplevel zone at the hoster is

    $ORIGIN xyz.com.
    jen IN NS dns1.foo.com. (running ISC BIND 9.3.2)
    jen IN NS dns2.bar.com. (also ISC BIND 9.3.2)

    $ORIGIN foo.com.
    dns1 IN A 1.2.3.4

    dns1's zone file is (shortened):

    $ORIGIN xyz.com.
    @ SOA ...
    IN A 1.2.3.4

    dns2 is configured as a slave to dns1. Trying to resolve xyz.com from
    anywhere in the world usually yields 1.2.3.4, which is ok.

    Now that dns1 is powered off, I noticed that xyz.com cannot be resolved
    anymore, even though that should have been the purpose of having slave
    servers, is not it?

    The dns2 logfile says

    Jul 27 11:44:16 dns2 named[5652]: zone jen.xyz.com/IN: refresh: retry
    limit for master 1.2.3.4#53 exceeded (source 0.0.0.0#0)
    Jul 27 11:44:16 dns2 named[5652]: zone jen.xyz.com/IN: Transfer started.
    Jul 27 11:44:19 dns2 named[5652]: transfer of 'jen.xyz.com/IN' from
    1.2.3.4#53: failed to connect: host unreachable
    Jul 27 11:44:19 dns2 named[5652]: transfer of 'jen.xyz.com/IN' from
    1.2.3.4#53: end of transfer

    Should not dns2 have kept the zones of the last successful transfer and use
    them?


    Jan Engelhardt
    --



  2. Re: Slave fails failover

    In article ,
    Jan Engelhardt wrote:
    >Hello,
    >
    >
    >as commonly done, I have two DNS servers for a domain, that is, the
    >toplevel zone at the hoster is
    >
    > $ORIGIN xyz.com.
    > jen IN NS dns1.foo.com. (running ISC BIND 9.3.2)
    > jen IN NS dns2.bar.com. (also ISC BIND 9.3.2)
    >
    > $ORIGIN foo.com.
    > dns1 IN A 1.2.3.4
    >
    >dns1's zone file is (shortened):
    >
    > $ORIGIN xyz.com.
    > @ SOA ...
    > IN A 1.2.3.4
    >
    >dns2 is configured as a slave to dns1. Trying to resolve xyz.com from
    >anywhere in the world usually yields 1.2.3.4, which is ok.
    >
    >Now that dns1 is powered off, I noticed that xyz.com cannot be resolved
    >anymore, even though that should have been the purpose of having slave
    >servers, is not it?


    Maybe dns2 is not in the lists of the delegated hosts. Check this
    with something like this:

    dig @a.gtld-servers.net. ns xyz.com.

    >The dns2 logfile says
    >
    >Jul 27 11:44:16 dns2 named[5652]: zone jen.xyz.com/IN: refresh: retry
    >limit for master 1.2.3.4#53 exceeded (source 0.0.0.0#0)
    >Jul 27 11:44:16 dns2 named[5652]: zone jen.xyz.com/IN: Transfer started.
    >Jul 27 11:44:19 dns2 named[5652]: transfer of 'jen.xyz.com/IN' from
    >1.2.3.4#53: failed to connect: host unreachable
    >Jul 27 11:44:19 dns2 named[5652]: transfer of 'jen.xyz.com/IN' from
    >1.2.3.4#53: end of transfer
    >
    >Should not dns2 have kept the zones of the last successful transfer and use
    >them?


    Are you sure the domainb is expired on dns2?
    You may use something like this to check:

    dig @dns2 soa xyz.com.

    regards

    winfried

    --
    Winfried Magerl - Internet Administration
    Siemens Business Services, 81739 Munich, Germany
    Internet-Mail: Winfried.Magerl@mch.sbs.de



+ Reply to Thread