[Opendnssec-user] SOA queries -> ServFail?

Havard Eidnes he at uninett.no
Wed May 31 09:25:32 UTC 2017

>> Turns out that this is in response to the SOA queries it issues:
>> 14:49:39.571605 IP xxxx.42494 > yyyy.domain: 21758 [2au] SOA? 58.39.128.in-addr.arpa. (140)
>> 14:49:39.572698 IP yyyy.domain > xxxx.42494: 21758 ServFail- 0/0/2 (140)
>> Is this expected behaviour, i.e. are SOA queries not part of the
>> reportoire which OpenDNSSEC implements?  If so, that's a surprise...
> OpenDNSSEC should respond to SOA queries. There are a couple of cases
> where it isn't able to. See the soa request function [1]. Maybe the zone
> is expired? In any case you should find some hint in the logs of the
> signer. grep for "[axfr]" in combination with "58.39.128.in-addr.arpa".
> This should, according to the code provide some additional information.

The above corresponds with:

May 30 14:49:40 xxxx named[384]: zone 58.39.128.in-addr.arpa/IN: refresh: unexpected rcode (SERVFAIL) from master (source

and on OpenDNSSEC:

May 30 14:49:39 yyyy ods-signerd: [axfr] zone 58.39.128.in-addr.arpa expired at 1495767753, and it is now 1496148579: not serving soa (serial_xfr_acquired=1495162953, expire=604800)

1495767753 = Fri May 26 05:02:33 CEST 2017
1495162953 = Fri May 19 05:02:33 CEST 2017
604800 = 7 days

So, yes, it seems that OpenDNSSEC in this instance has expired the
zone.  But why?  The upstream name server (the hidden master) still
serves the zone, with the AA flag set in its responses, with the same
SOA version# that OpenDNSSEC saw when it transferred the zone
initially.  The zone has not been touched/updated on the hidden master
for quite a while.

Doesn't OpenDNSSEC periodically query the upstream hidden master about
its SOA version number, and update the "serial_xfr_acquired" timestamp
after it has verified that no change in the SOA version number has
occurred at the master?  It seems to me that OpenDNSSEC expires zones
when it should not...


- Håvaard

More information about the Opendnssec-user mailing list