Open jpmens opened 2 years ago
This is a deliberate design choice. Do you actually want the zone to expire?
I wasn't expecting that question. :-)
I can't find any mention of this design choice or behavior in the documentation, so maybe I have to rename / resubmit this issue as a documentation enhancement?
It is very true that the fields have complicated and sometimes controversial meanings. Maybe all the more reason to mention that SOA expire isn't used in PowerDNS.
I wasn't expecting that question. :-)
It turns out, most people were not expecting expiry!
I agree we either need to fix this (maybe) or document this well (my favourite choice).
Best to document all SOA fields and their (non-)use in PowerDNS.
@jpmens if you look at RFC - https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.13
EXPIRE A 32 bit time value that specifies the upper limit on the time interval that can elapse before the zone is no longer authoritative.
This is really big problem for me, my case for example :
pdns with psql backend as master and 3x pdns as AXFR slaves.
Before removing zone from master (via api), my app set expire, send notify, after this i remove zone.
And i expect SERVFAIL
or REFUSE
for queries to slaves.
Short description
PowerDNS Authoritative with the BIND backend does not expire a secondary zone when the SOA expire timer elapses.
Environment
Steps to reproduce
pdns.conf
named.conf
Launch PowerDNS
Query the server
Expected behaviour
I expected PowerDNS to expire the secondary zone, having it
SERVFAIL
orREFUSE
queries to it. (BIND 9.16, Knot DNS 3.1.4, and NSD 4.3.8 reportSERVFAIL
)Actual behaviour
The zone is not expired and continues being available for queries. The time elapsed between the diagnostic that the zone transfer was complete until I stopped the test was 19 minutes and 19 seconds.