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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
