Allow only temporary zone updates without making them permanent

Grant Taylor gtaylor at tnetconsulting.net
Sun Jun 30 17:34:15 UTC 2019


On 6/30/19 3:38 AM, Lefteris Tsintjelis via bind-users wrote:
> If you do it manually yes; if you do it automatically from a cron job, 
> everything is timed.

How does using a cron job change things?

Let's Encrypt (or other ACME providers) behaves the same way for manual 
client operation as they do for automated client operation.

> Again, no it is not required but only if you do it manually.

Dynamic* zones are not /required/ period.  It doesn't matter if it's 
manual or automatic.

You can write a script something that does the following:

1) Collect the new value from the ACME client.
2) Modify the zone file with something like sed or a strategically 
constructed patch (including serial).
3) Have BIND reload the zone and notify peers of the new serial.
4) Wait some time for zone transfers to happen.
5) Query all servers to confirm they have the new value.
6) Re-run the ACME client to complete the renewal process.

> The idea here is to automate everything and,

I think steps 1-6 are automated or at least easily automatable.

> unless I am missing something, there is no other way to do this.

I think you're missing options that are outside of the box.  ;-)

> There has to be a dynamic zone for the ACME records.

No, there does not.

There has to be a way to get new data into the zone.  That does not 
/require/ a dynamic* zone.

There are a number of ways to update data in a DNS zone file.

  · Dynamic* DNS
  · Dynamically Loadable Zones (http://bind-dlz.sourceforge.net/)
     · File System structures
     · Berkeley DB
     · PostgreSQL
     · MySQL
     · ODBC
     · LDAP
     · Stub
  · Specially crafted Response Policy Zone
  · Specially crafted Response Policy Service
  · Editing static text DNS zone files

The RPZ option might seem strange.  But I think you could create a tiny 
RPZ that matched known values from the static zone and replaced them 
with the updated value from ACME.  I think this could be made to work 
with a tiny specific use RPZ that was rebuilt with the new data from the 
ACME client.

I'm sure there are more options.  Just be creative and think outside of 
the options that BIND provides.

Suffice it to say, I'm quite confident that Dynamic* zones are /NOT/ 
/required/ to support automation of ACME client operation using DNS for 
authentication / authorization.  I'm confident enough that I'll bet $50 
USD on it.  }:-)

* RFC 2136 - Dynamic Updates in the Domain Name System (DNS UPDATE)



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4008 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190630/8b28665b/attachment.bin>


More information about the bind-users mailing list