Allow only temporary zone updates without making them permanent

Lefteris Tsintjelis lefty at spes.gr
Sat Jun 29 20:13:42 UTC 2019


On 29/6/2019 21:55, Grant Taylor via bind-users wrote:
> On 6/29/19 12:30 PM, Lefteris Tsintjelis via bind-users wrote:
>> Secondaries though are almost always slaves, so writing suppression
>> doesn't really matter for them. It is the primary that only matters so
>> if it could suspend writing for just one minute then everything would
>> complete perfectly OK. The ACME record doesn't have to be permanently
>> stored anywhere.
> 
> Hypothetical scenario:  Secondary (slave) does not receive a notify,
> waits and polls the Primary (master) per standards DNS mechanisms.
> 
> If the secondary (slave) has a sufficiently old serial (say it's been
> offline for maintenance), it will see the new serial and do a zone
> transfer, including the temporary ACME records.
> 
> Timing and other conditions might make this unlikely to happen, but I
> think that it is a possibility.

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. When I tried it (by a mistake) with a
secondary not synchronized properly (older serial) ACME failed. I
suppose all this means automatically that the zone MUST be dynamic in
order for named to handle all that and propagate everything properly.

>> Thank you! This is the "proper" way to do it. I have tested the
>> _acme-challenge only dynamic zone as you described it and it worked
>> perfectly well and as expected but there is a quite a lot to do for
>> just one record for one minute in order to work properly.
> 
> This is why some people say "pick the lesser of the evils".  ;-)

But DNS, even with all this trouble for just one record, is the less
evil!!! Using http ACME would have been hell! I deal with a few domains
and various flavors of OSs and web servers and setups so you can imagine
how would that one be! At least DNS is more centralized and unified for
me, paradise actually compared to the http ACME verification option! :-)

>> I am not sure about the CNAMEs. It sounds easier to implement as there
>> is only one dynamic zone for all hosts but I am not sure how. The
>> _acme-challenge.<host>, from what I know, is expected to be within the
>> main domain zone in order for ACME to work properly, so how would it
>> work in a separate dynamic one? Wouldn't ACME reject it?
> 
> The _acme-challenge.<host> record name is expected to be within the main
> domain zone.  But there is nothing that prevents that record from being
> a CNAME to another zone.
> 
> _acme-challenge.www.example.org is a CNAME to www.example.org.dynamic.local
> _acme-challenge.www.example.net is a CNAME to www.example.net.dynamic.local
> _acme-challenge.www.example.com is a CNAME to www.example.com.dynamic.local
> 
> So the only dynamic zone is dynamic.local.  Yet ACME clients can query
> their expected names, follow the CNAME, and get the data they need.

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.

Lefteris


More information about the bind-users mailing list