Hello,
I think this is useful in a very limited way. The reason of this
limitation is already stated in section 1:
> The RRSERIAL EDNS extension doesn't offer much relevance for zones
served by an Authoritative server that don't use the SOA serial
versioning as a meaning to its content. There are cases where
nameservers use different backends for its data sources, like relational
databases or by using a different off-DNS synchronicity. In such cases
this extension has no benefit or utility to use in debugging or analysis
of a response.
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)
To handle the traditional SERIAL together with more "modern" backends I
propose simple modification to extend this draft to handle both.
Say that wire format could look like:
<length field, 2 octets, unsigned int>
<backend specific data with length specific above>
This allows the auth server to either send (length=2,data=4) with SOA
serial as usual, or return any other identification suitable for a given
backend.
If we _really_ wanted we could add also type field to distinguish
"traditional" SERIAL vs. backend-specific blob, but I think it is not
really needed.
To me this is very simple addition which increases value of the proposed
protocol.
Opinions?
Petr Špaček
On 06. 04. 22 16:26, Hugo Salgado wrote:
Dear DNSOP.
The authors have just reactivated the draft after its expiration, with
no changes. After some time waiting for other more urgent documents, we
believe that we can now reactivate it in the WG and ask for your
opinions. The last comments and suggestion were acknowledged, and we
think we could be close to Last Call.
As this document indicates where I have tried to keep track of work
(https://github.com/huguei/rrserial) there's a new implementation in
NSD and a couple of clients (dig and perl Net::DNS).
Currently we're working in an infrastructure for a public testbed that
we'll make available for implementers.
Thanks,
Hugo
On 07:08 06/04, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : The "RRSERIAL" EDNS option for the SOA serial of a
RR's zone
Authors : Hugo Salgado
Mauricio Vergara Ereche
Filename : draft-ietf-dnsop-rrserial-01.txt
Pages : 6
Date : 2022-04-06
Abstract:
The "RRSERIAL" EDNS option allows a DNS querier to request a DNS
authoritative server to add an EDNS option in the answer of such
query with the SOA serial number field of the origin zone which
contains the answered Resource Record.
This "RRSERIAL" data allows to debug and diagnose problems by helping
to recognize the data source of an answer in an atomic single query,
by associating the response with a respective zone version.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rrserial/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-rrserial-01.html
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rrserial-01
Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
