[Opendnssec-user] SOA queries -> ServFail?

[Havard Eidnes]

Hi,

I'm using DNS AXFR/IXFR to transfer zones out of my OpenDNSSEC
installation. Today I had occasion to look a bit closer at what
the downstream BIND was logging, and it logged all too frequently
that OpenDNSSEC returned a "SERVFAIL" error response.

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)
14:49:40.071747 IP xxxx.42892 > yyyy.domain: 55296 [1au] SOA? 58.39.128.in-addr.arpa. (129)
14:49:40.073077 IP yyyy.domain > xxxx.42892: 55296 ServFail- 0/0/1 (129)

Is this expected behaviour, i.e. are SOA queries not part of the
reportoire which OpenDNSSEC implements? If so, that's a surprise...

This is with OpenDNSSEC 1.4.13.

Regards,

- Håvard

[Yuri Schaeffer]

Hi Håvard,

Post by Havard Eidnes
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.

Best regards,
Yuri


[1]
https://github.com/opendnssec/opendnssec/blob/1.4/master/signer/src/wire/axfr.c#L53

[Havard Eidnes]

Post by Yuri Schaeffer

Post by Havard Eidnes
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 158.38.3.18#53 (source 0.0.0.0#0)

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...

Regards,

- Håvaard

[Yuri Schaeffer]

Hi Havard,

Post by Havard Eidnes
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?

We just had a discussion about this. It seems that OpenDNSSEC doesn't
actively probes for a new version but yet expires the zone when no
changes where received for a while. So a DNS input adapter in
combination with a static zone is an unfortunate combination.

We did not reach consensus why it works like this. Oversight, maybe bad
assumptions in the past. (the DNS based adapters weren't added from the
start of the project). Or even if OpenDNSSEC should even ever expire a
zone at all. Answer: it depends whether you consider OpenDNSSEC owner of
the zone.

On the long term we should implement active probing (for version > 2.X).
We are in the middle of a major Signer overhaul so we won't have that
soon. I do think however that for the short term it would be wise to
entirely disable the expiry logic in 1.4. Would it be acceptable to
never expire a zone even if the master goes away?

//Yuri

[Havard Eidnes]

Post by Yuri Schaeffer

Post by Havard Eidnes
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?

We just had a discussion about this. It seems that OpenDNSSEC doesn't
actively probes for a new version but yet expires the zone when no
changes where received for a while. So a DNS input adapter in
combination with a static zone is an unfortunate combination.

That ought to be a fully supported and normal combination...

Looking at packet capture, it seems that my OpenDNSSEC does periodic
IXFR attempts, and even if there has been no change, the SOA record
for the zone is part of the response from the hidden master. The
question is if you can piggyback the "query for SOA" functionality on
top of this, and note that the SOA record is the same as the one you
already have received, thus pushing the expiry timestamp into the
future?

I'm not sure I like your suggestion of turning off the expiry logic...

Regards,

- Håvard

[Yuri Schaeffer]

Post by Havard Eidnes
Looking at packet capture, it seems that my OpenDNSSEC does periodic
IXFR attempts, and even if there has been no change, the SOA record
for the zone is part of the response from the hidden master.

hmm that changes things. I'll take another look at this in the coming days.

//Yuri