W dniu 08.07.2019 o 22:30, Wessels, Duane pisze:
>
>
>> On Jul 8, 2019, at 1:05 PM, Witold Krecicki <[email protected]> wrote:
>>
>> W dniu 08.07.2019 o 19:20, Wessels, Duane pisze:
>>
>>> With respect to 2.6. Interaction with ZONEMD, I'd think it should follow
>>> handling of DNSSEC. That is, covert types should not be included in a zone
>>> digest.
>>
>> As I understand ZONEMD main purpose is to verify the full content of the
>> zone, mainly for zone transfer. In that case, I'd include COVERT records
>> - as the clients who can transfer the zone using XFR will also be able
>> to transfer COVERT records. (but I'm not stuck to that opinion).
>
> If the primary server is allowed to transmit two versions of the zone -- one
> with covert RRs and one without -- then it only makes sense to omit covert
> RRs from the digest. It would be unfortunate, but necessary.
>
> Actually I think the last paragraph of 2.2 would be better with only this:
>
> If the primary server receives a zone transfer request for a zone with
> Covert RRs, but without the COVERT-OK option, it MUST NOT transfer the
> zone.
>
> That is, don't allow AXFR of a zone with Covert RRs to an unaware secondary.
> Then leaks are much less likely and you can include the covert RRs in the
> zone digest. You would need to specify what the server should do in this
> case. REFUSED I guess.
The alternative is to transfer the zone without COVERT RR's if (and only
if) a configuration option is set - this is to make it easier during
'transition period' where primary supports Covert and secondary doesn't
- e.g. for NOTE RRs which are not critical to functioning of the zone.
The default behaviour is to refuse the transfer.
You're definitely right about specifying an exact response (REFUSED) if
a zone transfer request without COVERT-OK is received for a zone with
COVERT RR's and without the configuration option, I'm adding it to my
TODO list.
Witold
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
