Allow only temporary zone updates without making them permanent

Grant Taylor gtaylor at tnetconsulting.net
Sat Jun 29 21:29:53 UTC 2019


On 6/29/19 2:13 PM, Lefteris Tsintjelis via bind-users wrote:
> Standard DNS mechanisms and poll would not work. Everything must 
> be done within 1 minute so notify MUST be used and therefor zone 
> serial must be increased and of course all secondaries MUST be online 
> and respond to the notify properly and sync.

I think we've experienced different things with ACME clients.

Yes, the update needs to be propagated to all the (responding) servers. 
But I've not had any problems if it has taken five or more minutes.  I 
don't know what the timeout is.  But It's longer than one minute.

I've routinely manually run my ACME client, gotten the new TXT record, 
published it to my master server, waiting for it to propagate to the 
slaves, and then run my ACME client for Let's Encrypt to see the updated 
record in DNS.

I know I've been as slow as five minutes before.  I think I've been as 
slow as ten to fifteen minutes before.

> When I tried it (by a mistake) with a secondary not synchronized 
> properly (older serial) ACME failed.

Yes, incorrect data will cause ACME to fail.  But that's largely 
independent of timing.

> I suppose all this means automatically that the zone MUST be dynamic in 
> order for named to handle all that and propagate everything properly.

Nonsense.

There is nothing that states that you can't manually update your zone, 
remembering to increment the serial number, and then restarting BIND or 
reloading the zone.

BIND will send notifies as it's configured to do so.  Slaves will 
eventually do a zone transfer as specified in the SOA record if they 
miss the notify.

My experience has been that a sequence of events needs to be completed.

None of this /requires/ dynamic zones.

> But DNS, even with all this trouble for just one record, is the 
> less evil!!! Using http ACME would have been hell!

Agreed.

> Yes, but that would automatically place it in a completely different 
> domain. Isn't ACME "smart" enough to see this and fail? I have serious 
> doubts about this but I will check it.

No it would not.  It should not fail.

ACME will see a record at the expected name.  That record will be a 
CNAME to something else.  That other thing has the expected data which 
is required to authenticate.

Why should this fail?

You're free to have your doubts.  I'm the second person that recommended 
you use it.  I'd encourage you to /try/ it.  Find out for yourself if it 
works or not.

"Trust" (or not) that it will work.  "But Verify" for yourself.  ;-)



-- 
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/20190629/b5174668/attachment.bin>


More information about the bind-users mailing list