Subject: [DNSOP] Adoption of new EDNS opcode "rrserial"

From: Hugo Salgado <[email-masked]>
Date: Mon, 27 Jan 2020 12:08:47 -0300

Dear DNSOPers, as an operator I tend to have this need to couple
an answer for a query to an auth server, with the actual "SOA zone
version" used. So I think it'll be valuable to have an EDNS option
for it.

Here I'm proposing it with this new draft. The 'camel index' for
its implementation/hack/proof-of-concept is about 37 lines in
NSD 4.1 (more details in Appendix A).

I've asked some operators and they see value on it. Is there any
support for adoption in DNSOP?

-----
Name:           draft-salgado-rrserial
Revision:       01
Title:          The "RRSERIAL" EDNS option for the SOA serial of a RR's zone
Document date:  2020-01-27
Group:          Individual Submission
Pages:          5
URL:            https://www.ietf.org/internet-drafts/draft-salgado-rrserial-01.txt
Status:         https://datatracker.ietf.org/doc/draft-salgado-rrserial/
Htmlized:       https://tools.ietf.org/html/draft-salgado-rrserial-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-salgado-rrserial
Diff:           https://www.ietf.org/rfcdiff?url2=draft-salgado-rrserial-01

Abstract:
   The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS
   authoritative server to add a 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 problems and diagnosis by
   helping to recognize the origin of an answer, associating this answer
   with a respective zone version.
-----

Best,

Hugo Salgado

---

From: Hugo Salgado <[email-masked]>
Date: Tue, 28 Jan 2020 11:36:04 -0300

Hi Duane.

On 20:49 27/01, Wessels, Duane wrote:
> Hi Hugo,
> 
> I like this proposal and think that DNSOP should adopt it.  I agree that it will prove valuable in debugging.
> 

Great.

> A couple of comments and suggestions:
> 
> Sections 2 and 3 could be clarified regarding the value for OPTION-LENGTH.  I gather the intention is that OPTION-LENGTH is zero for queries and 4 for responses.
> 

Yes, that's the intention. I'll make it explicit in section 2.

> The "MUST" in section 3.2 feels too strong to me, absent any other text that says this feature is optional to implement or support.  Maybe include some text similar to whats in RFC 5001.  e.g., "A name server that understands the RRSERIAL option and chooses to honor a particular RRSERIAL request responds by ..."
> 

You're right, it'll be an optional/experimental feature. I'll modify the
text in this sense.

Thanks a lot!

Hugo

---

From: Shane Kerr <[email-masked]>
Date: Wed, 29 Jan 2020 11:57:38 +0100

Hugo,

>     with a respective zone version.

One possible application of this might be to allow a resolver to extend 
the TTL of an entire zone.

This is an idea that either Mukund Sivaraman or Stephen Morris came up 
with a couple of years ago (I can't remember who) and we discussed. The 
basic idea is that if your zone does not change frequently and uses SOA 
serial to indicate new versions of the zone, then you can return the SOA 
serial and then a resolver can "reset" all of the TTL counters for every 
RR that it has cached in the zone.

So, imagine you have:

postbox.zone.test MX ..., TTL 900, expires in 460 seconds
www.zone.test AAAA ...., TTL 60, expires in 1 second

You get back a response for a lookup of an A record for www.zone.test 
that says that the zone serial for zone.test has not changed, then you 
could end up with a cache that looks like:

postbox.zone.test MX ..., TTL 900, expires in 900 seconds
www.zone.test AAAA ..., TTL 60, expires in 60 seconds
www.zone.test A ..., TTL 60, expires in 60 seconds

IIRC this was even suggested in one of the very early DNS RFC as an area 
for research. The question is whether it is actually worth doing this, 
as you will have to keep track of the TTL as well as the expiration of 
each RR, and do the update on each new lookup.

Plus if your resolver was optimistically sending such an option with 
every query, you'd probably only want to include the EDNS option for 
servers that you think might support it, which means tracking that 
additional information in the server address cache/database that your 
resolver has.

As far as the wire format & protocol behavior, I think the changes from 
this draft needed would be:

* Returning the entire signed SOA in the additional section, rather than 
just the serial in an EDNS record (for DNSSEC validation purposes).
* Including an EDNS option in the response indicating that it is okay 
for a resolver to extend the TTL of other records in the zone.

Even just using SOA in the response instead of the serial in an EDNS 
record would be enough to allow later work on the TTL-extending 
technique, if we're squeamish about adding to the DNS camel. 😊

Cheers,

--
Shane

---

From: Tony Finch <[email-masked]>
Date: Wed, 29 Jan 2020 14:11:29 +0000

> just the serial in an EDNS record (for DNSSEC validation purposes).

I think it would be more traditional to put it in the AUTHORITY section :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lough Foyle to Carlingford Lough: Southwest 5 to 7. Slight or moderate for a
time in east, otherwise moderate or rough, occasionally very rough in north.
Occasional rain or drizzle. Moderate or good, occasionally poor.

---

From: Vladimír Čunát <[email-masked]>
Date: Wed, 29 Jan 2020 15:26:59 +0100

Hello.

On 1/29/20 11:57 AM, Shane Kerr wrote:
> One possible application of this might be to allow a resolver to
> extend the TTL of an entire zone.

Overall I suspect the TTL-extending use case might be sufficiently
different (and much more complicated) to consider separately/independently.

> As far as the wire format & protocol behavior, I think the changes
> from this draft needed would be:
>
> * Returning the entire signed SOA in the additional section, rather
> than just the serial in an EDNS record (for DNSSEC validation purposes).
> for a resolver to extend the TTL of other records in the zone

I haven't thought that much about it, but I'm not convinced that
validating the SOA (serial) would really help.  The main related problem
I see is signature validity of the records that get extended, i.e.
all/any of them and not just SOA.

As long as RRSIG of an RRset holds, resolvers can be "spoofed" to serve
that RRset, regardless of original TTL... so why would the attacker
bother to spoof SOA serial instead?  On the other hand if RRSIG expires,
I don't think even validating SOA serial would be enough to keep serving
this RRset, as e.g. downstream couldn't validate it normally.

> technique, if we're squeamish about adding to the DNS camel. 😊 

In suitable zones (e.g. root) I can imagine the resolver explicitly
querying for SOA in order to extend all the TTLs (though not beyond
RRSIG validity).  Still, generally there needs to be at least some way
for zones to opt out from any such TTL-extending technique.

Maybe utilizing ZONEMD should be considered instead.

--Vladimir

---

From: Hugo Salgado <[email-masked]>
Date: Wed, 29 Jan 2020 12:07:32 -0300

> different (and much more complicated) to consider separately/independently.

I think so, too. 

The original technique aims at debugging, so it does not consider
the spoof factor, and being hop-to-hop it is not allowed to be
exposed in resolvers either.

This extension could still be useful in that use case if we can take
advantage of a future secure resolver-authoritative channel (ADoT),
assuming we can get aroung the other problems (RRSIG expirations,
authoritative signaling, etc).

Anyway, if it's adopted and WG agreed, we could change this
draft to the "complete SOA+RRs in additional" answer, and it will
certainly solve my original debugging need O:)

Hugo

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 30 Jan 2020 04:24:12 -0500

> On Jan 29, 2020, at 9:11 AM, Tony Finch <[email-masked]> wrote:
> 

I see the ":-)", I take it you're not actually suggesting this...

If the reply is an authoritative negative reply, it will already have
an SOA in the authority section and EDE option repeating the same is
then clearly redundant.  Which argues in favour of doing this, ...

BUT, a gratuitous SOA in the authority section will likely also require
a corresponding RRSIG, which noticeably raises the packet size of the
response making the debugging option too costly, possibly leading to
truncation (defeating the intent to debug the response as-is).

Since this is for debugging only, no RRSIG is needed, and using an
EDE option for the response seems to make sense.

-- 
	Viktor.