Re: how two dns bind master sync?

2018-08-24 Thread Dave Warren

On 2018-08-23 14:15, Grant Taylor via bind-users wrote:

On 08/23/2018 01:20 PM, Barry S. Finkel wrote:
Somehow, under the covers, AD synchronizes the zones so that they have 
the same content.


It's my understanding that MS-DNS servers hosting AD Integrated zones 
are actually functioning as application layer gateways between DNS and 
data that's stored in LDAP.


So the case of synchronizing records with different FQDNs is actually 
trivial in that different records are being updated in the back end LDAP 
and the ALG is simply reading the data and replying to clients.


I don't know how to account for the serial number.  I think I've seen 
something like an encoded form of the date / time be used.  ¯\_(ツ)_/¯


tl;dr: The Active Directory logic for the serial number is simple: Each 
update to the zone increments the serial as you expect locally. When DCs 
sync they use the highest serial number of either, +1.


Imagine you have 3 (or more) servers, updates happening everywhere. The 
is an unknown period of latency between updates, not all DCs receive 
updates at the same time, and not all DCs receive updates in the same 
order or use the same schedule.


Start off with serial 100.
Server1 updates, increments to serial 101.
Server1 updates, increments to serial 102.
Server1 updates, increments to serial 103.
Server2 updates, increments to serial 102.
Server1 updates, increments to serial 104.
Server3 updates, increments to serial 102.

At this point all three have different views of the zone, with serials 
104, 102, 102 respectively.


Server2 and Server3 now sync, highest serial is 102 so both are set to 
103. Server1 and Server2 now sync, highest serial is 104 but there are 
other changes, so both increment to 105. Eventually Server1 and Server3 
sync, highest serial is 105, but no other records have changed so both 
agree to 105 and now everything is in sync once again.


Neither Active Directory nor Microsoft DNS care what is in the SOA 
record in terms of the refresh, retry and expire intervals, DNS records 
will instead synchronize around Active Directory along with every other 
type of change.


If you set BIND slaves to master off of just server1 there are no 
problems at all as the serial increases in a predictable and normal way. 
If your BIND slaves off of multiple AD DCs then it will 1) Periodically 
see and complain about (log) older serial numbers, and 2) Perodically 
flip between the zone as reported by the different servers.


However, a lot of this happens if the DCs are sending notifies to BIND 
and BIND is then changing it's mind about which master to use. If you 
only have one DC send notifies then (I believe) BIND will tend to just 
pull updates from that one DC and everybody is happy. If that DC goes 
down then BIND will eventually hit the refresh interval and (if 
configured) try other masters.


Happy weekend all!
___
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


Re: Sign ZSK key permanently

2018-08-24 Thread Paul van der Vlis
Hi Tony,

Thanks for your answer!

Op 23-08-18 om 18:40 schreef Tony Finch:
> Paul van der Vlis  wrote:
>>
>> Is it possible to sign the ZSK key permanently with the KSK key?
>> In this way I could keep the KSK key offline.
> 
> The only(*) revocation mechanisms in DNSSEC are expiring signatures and
> replacing keys. If you sign your DNSKEY records permanently, when anyone
> manages to compromise them they will be able to spoof records in your zone
> until you replace the KSK.
> 
> In effect, what you will have done is coupled the keys together
> permanently so they are of equivalent power, and eliminated all benefit of
> keeping the KSK offline.
>
> The point of an offline KSK is to allow you to recover from compromise of
> your ZSK without having to replace your DS records or other trust anchors.

If the ZSK and KSK are on the same place, they will be compromized
together I would say.

> It's worth having a look at how the root DNSKEY RRset is managed: they get
> the KSK out of storage a few times a year, when they generate RRSIG
> records for the next few months.

A long TTL is needed then.

> (*) The other mechanism is the RFC 5011 revoked bit, which only applies to
> KSKs that are being tracked as auto-updating trust anchors (managed-keys
> etc.) but that doesn't apply to other records that depend on signature and
> key rotation for revocation.
Isn't it possible to revoke the ZSK key, and sign the zone with a new
ZSK key?

Without an offline KSK, I do not see a reason for both a KSK and a ZSK
key. Do you?

With regards,
Paul van der Vlis

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/
___
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