debug SERVFAIL

[Per olof Ljungmark]

On 2016-10-02 17:02, Reindl Harald wrote:
> 
> 
> Am 02.10.2016 um 17:00 schrieb Per olof Ljungmark:
>> On 2016-10-02 16:50, Reindl Harald wrote:
>>>
>>>
>>> Am 02.10.2016 um 16:46 schrieb Per olof Ljungmark:
>>>> What is the best way to debug a SERVFAIL problem? I have tried to ramp
>>>> up the trace level a lot but that did not return anything useful.
>>>>
>>>> It is only one zone in question, namely the PTR for our external
>>>> subnet.
>>>> What puzzles me the most is that a secondary on the same subnet answers
>>>> just fine for thesame query. All forwards zones resolves good as well.
>>>>
>>>> BIND version is 9.10.4-P3
>>>
>>> most likely some error in the zonefile, look at named logs
>>>
>>> that the secondary answers is normal because if the master refuses to
>>> load a zone it never reaches the slave and start to fail there only when
>>> it expires before the error is fixed
>>>
>>> hence master/slave while in most environemnts you could technically
>>> generate the identical zone-files on all nameservers but then with the
>>> same errors and so all would fail (in case of PTR and mailservers with
>>> horrible results)
>>
>> There is nothing useful in the logs, hence my question above. The zone
>> files are identical on master and slaves so I doubt there is a problem
>> with that.
> 
> you need to provide the startup logs as well as the log-configuration

Hmmm, looks like I've found something here. The default named.conf on
FreeBSD has the following section on the root servers. If I comment out
the "traditional" root hints and instead use what is recommended below,
all reverse lookups will generate a SERVFAIL.

This is in the log:
zone in-addr.arpa/IN: refresh: non-authoritative answer from master
192.5.5.241#53 (source 0.0.0.0#0)

Would be interesting to hear comments.

<snip>

// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };

/*      Slaving the following zones from the root name servers has some
        significant advantages:
        1. Faster local resolution for your users
        2. No spurious traffic will be sent from your network to the roots
        3. Greater resilience to any potential root server failure/DDoS

        On the other hand, this method requires more monitoring than the
        hints file to be sure that an unexpected failure mode has not
        incapacitated your server.  Name servers that are serving a lot
        of clients will benefit more from this approach than individual
        hosts.  Use with caution.

        To use this mechanism, uncomment the entries below, and comment
        the hint zone above.

        As documented at http://dns.icann.org/services/axfr/ these zones:
        "." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
        are available for AXFR from these servers on IPv4 and IPv6:
        xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
        type slave;
        file "/usr/local/etc/namedb/slave/root.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
zone "arpa" {
        type slave;
        file "/usr/local/etc/namedb/slave/arpa.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
*/

<snip>