Subject: Re: [DNSOP] Call for Adoption: draft-salgado-dnsop-rrserial

From: Shane Kerr <[email-masked]>
Date: Tue, 1 Jun 2021 08:59:58 +0200

Hugo,

While I find it a pity that the consensus seems to be that just 
including the serial instead of the entire SOA is the best way forward, 
I don't strongly object, since it can indeed be useful for debugging as 
proposed.

Sorry if I missed earlier discussion, but if a query to a resolver 
arrived with the option sent, why not let the resolver pass it along and 
return the value? And maybe cache the value if desired? Or even use the 
option with some or all queries upstream without being asked? Surely 
being able to see the serial associated with records at a resolver could 
also be useful?

At the very least, maybe the draft should be agnostic towards 
non-authoritative servers?

So instead of:

    This EDNS option is aimed only to authorative servers for a zone.
    Resolvers and forwarders should ignore the option.  It's only
    intended for hop-to-hop communication (not transitive).

Maybe:

    This EDNS option is aimed only at authoritative servers for a zone.
    It's only intended for hop-to-hop communication (not transitive).
    Resolver and forwarder behavior is undefined.

Cheers,

--
Shane

On 31/05/2021 18.15, Hugo Salgado wrote:
> Dear group.
> Thanks for the call for adoption. We the authors are already working
> on -01 with the comments made a few weeks ago. I hope to send it in
> the next days for your review/approval.
> 
> Hugo
> 
> On 10:26 28/05, Tim Wicinski wrote:
>> All
>>
>> We had a lot of good discussion of this draft when it first came out, and
>> the chairs want to put up a call for adoption.
>>
>> If you have already stated adoption of this draft, we will count those so
>> there is no need to repeat yourself.
>>
>>
>> This starts a Call for Adoption for draft-salgado-dnsop-rrserial
>>
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/
>>
>> Please review this draft to see if you think it is suitable for adoption by
>> DNSOP, and send comments to the list, clearly stating your view.
>>
>> Please also indicate if you are willing to contribute text, review, etc.
>>
>> This call for adoption ends: 22 June 2021
>>
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
> 
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Shane Kerr <[email-masked]>
Date: Tue, 1 Jun 2021 09:04:33 +0200

Tim,

On 28/05/2021 16.26, Tim Wicinski wrote:
 >
 > We had a lot of good discussion of this draft when it first came out,
 > and the chairs want to put up a call for adoption.

I support adoption of the draft, and am willing to contribute text and 
review.

Cheers,

--
Shane

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 01 Jun 2021 13:20:38 +0200

On Tue, 2021-06-01 at 08:59 +0200, Shane Kerr wrote:
> And maybe cache the value if desired?

I'm already looking forward to having serials in resolver cache dumps!

>     Resolver and forwarder behavior is undefined.

I like this. I suspect defining it well for answers from resolvers to
clients would open up a big can of worms that could kill the draft,
like many other drafts that have been crushed under the sheer weight of
scope creep.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Hugo Salgado <[email-masked]>
Date: Tue, 1 Jun 2021 10:05:53 -0400

> like many other drafts that have been crushed under the sheer weight of

Yes, fair enough. Furthermore, the draft currently avoids talking about
"client" and uses "querier", which from the authoritative point of view
could be a debugging human or a resolver.

Hugo

---

From: Joe Abley <[email-masked]>
Date: Tue, 1 Jun 2021 10:33:58 -0400

Hi Hugo,

> could be a debugging human or a resolver.

Some DNS documents have used the words "initiator" and "responder" to describe the actors involved in either side of an exchange of DNS messages. That might be worth considering.

I agree that avoiding the complication of caches makes sense. Perhaps linking the behaviour to AA header bit processing would be useful. An individual DNS server might be principally a resolver by function but might also respond authoritatively (AA=1) to some queries. Those queries ought to be in-scope for your mechanism, I think.

Joe

---

From: Davey Song <[email-masked]>
Date: Thu, 3 Jun 2021 12:13:38 +0800

Hi Hugo,

I like this draft. And I will continue to review and comment when you have
new versions.

Generally, it is helpful to figures out who answer my queries in the
troubleshooting process. So the draft is helpful if out-of-sync occurs
between authoritative servers, such as Hidden Masters, primary server, and
secondary servers.

Some thoughts out of the scope of this draft： I think the out-of-sync
issue is more serious which occurs between the broken cache resolver and
the authoritative servers when the cache resolver violates the TTL. Maybe
my queries are hijacked to that broken server. IMHO, there is a piece
missing to help troubleshooting which cache resolver answered my query and
which version of the zone the cached response is associated with.

The NSID option is proposed for authoritative sever.  Maybe we can propose
an NSID for cache resolver？ Any suggestions?

Best regards,
Davey

---

From: Hugo Salgado <[email-masked]>
Date: Thu, 3 Jun 2021 09:39:24 -0400

Hi Davey. Thanks for your support.
About the identification for resolvers, it's out of scope for this
draft, but nothing prevents the use of RRSERIAL and NSID in the
resolvers. Last paragraph of RFC5001 section 2.2 says so, and in
version -01 of this draft there'll be a relaxation by declaring the
use of rrserial in resolvers as undefined, thanks to Shane's
comments.

Of course the exact behavior needs to be defined more carefully, but
RRSERIAL would be a first step on that path.

Hugo

---

From: Davey Song <[email-masked]>
Date: Thu, 3 Jun 2021 21:56:47 +0800

> nothing prevents the use of RRSERIAL and NSID in the
> resolvers. Last paragraph of RFC5001 section 2.2 says so,

Yes. Thanks for pointing it out.

> and in
> use of rrserial in resolvers as undefined
>

I'm looking forward to that.

Davey

---

From: Benno Overeinder <[email-masked]>
Date: Mon, 7 Jun 2021 15:02:15 +0200

Hi Davey, all,

> Yes. Thanks for pointing it out.

RFC5001 is already implemented by a number of resolvers.

https://www.powerdns.com/compliance.html
https://www.nlnetlabs.nl/projects/unbound/rfc-compliance/
https://knot-resolver.readthedocs.io/en/stable/modules-nsid.html
https://www.isc.org/bind9rfc/

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 11 Jun 2021 10:03:04 -0400

All

The Call for Adoption has ended and there was some excellent comments and
suggestions. The WG has consider this adopted.

If the authors upload the new version with the new name of
draft-ietf-dnsop-rrserial
we would appreciate it.

thanks
tim

On Fri, May 28, 2021 at 10:26 AM Tim Wicinski <[email-masked]> wrote:

> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and send comments to the list, clearly stating your view.
>