Hi Matthijs,
Thank you for your helpful review! Please find some responses below:
On 1/9/25 14:09, Matthijs Mekking wrote:
Section 3
---------
"There MUST NOT be more than one DSYNC record for each combination of rrtype and
scheme."
I wonder what the argument is for this. Doesn't this prevent redundancy and
failover for notification targets?
The argument is that if there are several, then there are several ways to
handle that (use all? pick one? try sequentially? which sequence?).
The question of how to handle this situation was raised in the Dnsdir review [1]. The
authors figured that regardless of which strategy is specified, sender implementations
would most likely not implement that complexity, but try the "first", and fire
and forget. It seemed that simplicity would lead to more reliable operation in this case.
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/LFsvddryRr-aYM3BTGyo7My1bD0/
2. "If a DSYNC RRset results, return it."
This reads weird. I guess something like "If there is a validated positive DSYNC
answer, return it".
Fixed. ("If a positive DSYNC answer results, return it.")
The example in step 3 uses city.ise.mie.jp, but there are domain names reserved for documentation purposes
("example.", "example.com.", "example.net.", "example.org.", and any names
falling within those domains), so let's use one of these for the example.
Opinions differ; others found that particular example very useful [2].
We picked this because it is very illustrative, and because the existence of
reserved example names does imply that one cannot use other examples. However,
we're open to replacing the example; it would be great if you could in this
case suggest some text. (I did not manage to come up with one that's equally
instructive.)
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/6NRRI-p4Xsw0p9UVNIGuAuxhqQ0/
Thanks again,
Peter + co-authors
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
