Re: [DNSOP] I-D Action: draft-ietf-dnsop-rrserial-01.txt

[Petr Špaček <[e-mail]>]

On 07. 04. 22 20:31, Hugo Salgado wrote:
> On 17:30 07/04, Petr Špaček wrote:
>> On 07. 04. 22 15:47, Paul Vixie wrote:
>>> Petr Špaček wrote on 2022-04-06 23:54:
>>>> Hello,
>>>>
>>>> ...
>>>>
>>>>   From my perspective, these systems are not rare, quite the contrary:
>>>> - PowerDNS with a database backend
>>>> - Multi-master flavors of BIND
>>>> - Various "cloud" auths with dynamic backends
>>>> - Windows DNS with Active Directory (I think)
>>>
>>> because IXFR and NOTIFY and UPDATE use serial numbers, the DNS protocol
>>> itself is aware of serial numbers. i hope that any recognition of
>>> non-traditional serial numbers will be an optional addition to the
>>> RRSERIAL response, and that if a zone has no actual serial number (so,
>>> it cannot participate in IXFR, NOTIFY, and UPDATE) the RRSERIAL value
>>> will just be a magic number like zero, or just missing altogether.
>>
>> I fail to understand what you mean, can you elaborate?
>>
>> I will try to rephrase myself for clarity:
>>
>> "Let's make this draft _also_ usable for debugging e.g. PowerDNS and
>> multi-master BIND."
>>
> 
> Hi Petr, thank you for your suggestions.
> 
> The way we see RRSERIAL extension is just as a copy of the SOA serial
> value.
> 
> I think what you’re trying to describe on PowerDNS and multi-master
> BIND, is that the value contained there doesn’t offer any meaning;
> I assume it could be either 0 or 1 or any custom other value (and here,
> we can all agree there is a value). In such cases I would still expect
> an RRSERIAL answer with that specific value, irrespective if it has a
> meaning, and also, those implementations can just avoid to answer
> RRSERIAL queries (which BTW it is allowed). Did we understand that
> correctly, right?

Yes, that's exactly what I meant.

> So, maybe there's another way of accomplish this need: we can drop
> entirely this RRSERIAL option, and create a new "ZONEVERSION" EDNS
> option, that has a new meaning of... well... zone versioning :) So,
> this ZONEVERSION value would be the SOA serial number in classic zones
> (like this RRSERIAL proposal) but it would also add a new opaque
> meaning for the other server implementations. If this new value has
> another structure, then maybe we need a new field inside ZONEVERSION
> to differentiate it. If it's just a 32 bits unsigned number just like
> RRSERIAL, then it's a number, just not the same as the SOA serial value.

Yes, that's basically what I meant.

Let's sketch a wire format for ZONEVERSION option:
- 1 byte - flags
- 2 bytes - length L
- L bytes

Flags:
- bit 0 - is the value in fact SOA serial?

What do you think?

-- 
Petr Špaček

P.S. I'm going to be AFK for a week or so. Silence from my side does not 
mean I intentionally ignore responses.