Subject: [Doh] Does the HTTP freshness lifetime need to match the TTL?

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2018 21:29:04 +0000

There is an active discussion with lots of back-and-forth at:
   https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 May 2018 22:23:36 +0000

I'm going to re-up this here on the list. Please see the discussion on
   https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153

It would be handy if people who disagree with each other offer text *on the list*, not pull requests, specifying what they want the text in the draft to say. Then, people to try to come to consensus on this. (Yes, some people are more comfortable with editing pull requests; I feel that this issue is too important to not have the discussion here on the list.)

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 May 2018 10:10:53 +1000

> It would be handy if people who disagree with each other offer text *on the list*, not pull requests, specifying what they want the text in the draft to say. Then, people to try to come to consensu…

Proposal:

Cache Interaction {#caching}

A DNS API request can pass through a hierarchy of caches that include both HTTP and DNS specific caches. HTTP caches are by design generic; that is, they do not understand this protocol. Even if a DNS API client has modified its cache implementation to be aware of DOH semantics, it does not follow that all upstream caches (for example, in proxies, server-side gateways and Content Delivery Networks) will be.

As a result, DNS API servers need to carefully consider the HTTP caching metadata they send in response to GET requests (POST requests are not cacheable unless specific response headers are sent; this is not widely implemented, and not advised for DOH). 

In particular, they are encouraged to assign an explicit freshness lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby taking control out of the hands of the DNS API server.

Typically, the assigned freshness lifetime of a given DOH HTTP response will use the smallest TTL in the Answer section of the DNS response as a maximum. For example, if a HTTP response carries three RRsets with TTLs of 30, 600 and 300, the HTTP freshness lifetime usually ought to be no more than 30 seconds (e.g., "Cache-Control: max-age=30"), so that the RRset with the smallest TTL is not stale when retrieved from cache.

This assures that none of the RRsets contained within are served stale from an HTTP cache.

If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime typically ought not be greater than the MINIMUM field from that SOA record (see {{RFC2308}}).

The stale-while-revalidate and stale-if-error Cache-Control directives ({{?RFC5861}}) could be well suited to a DOH implementation when allowed by server policy. Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer fresh.

DNS API servers also need to consider caching when generating responses that are not globally valid. For instance, if a DNS API server customizes a response based on the client's identity, it would not want to allow global reuse of that response. This could be accomplished through a variety of HTTP techniques such as a Cache-Control max-age of 0, or by using the Vary response header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache key ({{RFC7234}}, Section 4.1).

DNS API clients MUST account for the Age response header's value ({{RFC7234}}) when calculating the DNS TTL of a response. For example, if a RRset is received with a DNS TTL of 600, but the Age header indicates that the response has been cached for 250 seconds, the remaining lifetime of the RRset is 350 seconds. 

DNS API clients that encounter stale responses (either because the HTTP freshness lifetime has passed, or because one or more RRset's lifetime has passed) can request a fresh copy by using the "no-cache" request cache control directive ({{RFC7234}}, Section 5.2.1.4) and similar controls. Note that some caches might not honour these directives, depending upon their configuration.

HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as revalidation provides only a bandwidth benefit and DNS transactions are normally latency bound. Furthermore, the HTTP response headers that enable revalidation (such as "Last-Modified" and "Etag") are often fairly large when compared to the overall DNS response size, and have a variable nature that creates constant pressure on the HTTP/2 compression dictionary {{RFC7541}}. Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation.

--
Mark Nottingham   https://www.mnot.net/

---

From: Miek Gieben <[email-masked]>
Date: Tue, 8 May 2018 09:45:45 +0000

[ Quoting <[email-masked]> in "Re: [Doh] [Ext] Does the HTTP fresh..." ]
>Cache Interaction {#caching}

I like this text, but is the working-group OK with *not* mentioning DNSSEC?

If you only look a the TTL and not the inception and expiry dates of RRSIGs you 
can easily serve BAD data.

/Miek

--
Miek Gieben

---

From: Tony Finch <[email-masked]>
Date: Tue, 8 May 2018 12:35:57 +0100

Miek Gieben <[email-masked]> wrote:
> If you only look a the TTL and not the inception and expiry dates of RRSIGs
> you can easily serve BAD data.

Mark's suggestion is pretty comprehensive in other areas, so I think it
ought to mention RRSIG expiry dates. (The upstream DNS server should have
fixed up the TTLs, but if you're going through the DNS packet to work out
an expiry time you might as well do it properly.)

The other possible addition is a reference to draft-ietf-dnsop-serve-stale
alongside the HTTP staleness considerations. But serve-stale is still a
draft and you probably don't want to make DoH wait for it.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: Northwesterly 4 or 5, occasionally 6 at first in northeast, becoming
variable 4 later. Moderate, becoming rough in west. Occasional drizzle.
Moderate or good, occasionally poor.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 8 May 2018 13:37:38 +0200

Thanks Mark,

This text reads more fluidly, and that is nice. OTOH it doesn't do much to
resolve the core tension in https://github.com/dohwg/
draft-ietf-doh-dns-over-https/issues/153. The current ID uses normative
language for creating http freshness lifetimes from DNS sets.

Comments from you and Martin (and this text suggestion) support changing
this from normative language to advice. The other comments favor the more
deterministic behavior we currently have.

Can you help me understand the argument you are making? Martin primarily
suggests having the DNS code check the TTL before use rather than relying
on the cache to serve fresh responses - but I think that particular point
has met significant pushback largely from the DNS experts in the community.

fwiw I think I agree with the existing normative requirement - a response
ought to be valid at the time of receipt and it is very helpful to
harmonize the concepts of DNS and HTTP valid. This doesn't preclude fancy
stuff like stale-if-error or insane client max-age headers if a client is
motivated.

The existing draft seems to have caused a little bit of confusion by saying
SHOULD match rather than MUST match.. The intent for that was to allow for
http lifetimes less than DNS lifetimes (particularly max-age:0 if you
cannot figure out the DNS lifetime from your HTTP server code). The
subsequent sentence enforced the >= property.

Is there another aspect to the question I'm missing?

On Tue, May 8, 2018 at 2:10 AM, Mark Nottingham <[email-masked]> wrote:

> > It would be handy if people who disagree with each other offer text *on
> the list*, not pull requests, specifying what they want the text in the
> draft to say. Then, people to try to come to consensus on this. (Yes, some
> people are more comfortable with editing pull requests; I feel that this
> issue is too important to not have the discussion here on the list.)
>
> Proposal:
>
> A DNS API request can pass through a hierarchy of caches that include both
> HTTP and DNS specific caches. HTTP caches are by design generic; that is,
> they do not understand this protocol. Even if a DNS API client has modified
> its cache implementation to be aware of DOH semantics, it does not follow
> that all upstream caches (for example, in proxies, server-side gateways and
> Content Delivery Networks) will be.
>
> As a result, DNS API servers need to carefully consider the HTTP caching
> metadata they send in response to GET requests (POST requests are not
> cacheable unless specific response headers are sent; this is not widely
> implemented, and not advised for DOH).
>
> In particular, they are encouraged to assign an explicit freshness
> lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign
> heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby taking
> control out of the hands of the DNS API server.
>
> Typically, the assigned freshness lifetime of a given DOH HTTP response
> will use the smallest TTL in the Answer section of the DNS response as a
> maximum. For example, if a HTTP response carries three RRsets with TTLs of
> 30, 600 and 300, the HTTP freshness lifetime usually ought to be no more
> than 30 seconds (e.g., "Cache-Control: max-age=30"), so that the RRset with
> the smallest TTL is not stale when retrieved from cache.
>
> If the DNS response has no records in the Answer section, and the DNS
> response has an SOA record in the Authority section, the response freshness
> lifetime typically ought not be greater than the MINIMUM field from that
> SOA record (see {{RFC2308}}).
>
> The stale-while-revalidate and stale-if-error Cache-Control directives
> ({{?RFC5861}}) could be well suited to a DOH implementation when allowed by
> server policy. Those mechanisms allow a client, at the server's discretion,
> to reuse a cache entry that is no longer fresh.
>
> DNS API servers also need to consider caching when generating responses
> that are not globally valid. For instance, if a DNS API server customizes a
> response based on the client's identity, it would not want to allow global
> reuse of that response. This could be accomplished through a variety of
> HTTP techniques such as a Cache-Control max-age of 0, or by using the Vary
> response header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache
> key ({{RFC7234}}, Section 4.1).
>
> DNS API clients MUST account for the Age response header's value
> ({{RFC7234}}) when calculating the DNS TTL of a response. For example, if a
> RRset is received with a DNS TTL of 600, but the Age header indicates that
> the response has been cached for 250 seconds, the remaining lifetime of the
> RRset is 350 seconds.
>
> DNS API clients that encounter stale responses (either because the HTTP
> freshness lifetime has passed, or because one or more RRset's lifetime has
> passed) can request a fresh copy by using the "no-cache" request cache
> control directive ({{RFC7234}}, Section 5.2.1.4) and similar controls. Note
> that some caches might not honour these directives, depending upon their
> configuration.
>
> HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as
> revalidation provides only a bandwidth benefit and DNS transactions are
> normally latency bound. Furthermore, the HTTP response headers that enable
> revalidation (such as "Last-Modified" and "Etag") are often fairly large
> when compared to the overall DNS response size, and have a variable nature
> that creates constant pressure on the HTTP/2 compression dictionary
> {{RFC7541}}. Other types of DNS data, such as zone transfers, may be larger
> and benefit more from revalidation.
>
>
> --
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 May 2018 21:54:32 +1000

> On 8 May 2018, at 9:37 pm, Patrick McManus <[email-masked]> wrote:
> 
> Thanks Mark,
> 
> This text reads more fluidly, and that is nice. OTOH it doesn't do much to resolve the core tension in https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153. The current ID uses normative language for creating http freshness lifetimes from DNS sets.

Well, Paul asked for text...

> Comments from you and Martin (and this text suggestion) support changing this from normative language to advice. The other comments favor the more deterministic behavior we currently have.
> 
> Can you help me understand the argument you are making? Martin primarily suggests having the DNS code check the TTL before use rather than relying on the cache to serve fresh responses - but I think that particular point has met significant pushback largely from the DNS experts in the community.

I'm not hearing pushback to this approach on this thread so far, so I'd like to hear (here) what the issue is.

> fwiw I think I agree with the existing normative requirement - a response ought to be valid at the time of receipt and it is very helpful to harmonize the concepts of DNS and HTTP valid. This doesn't preclude fancy stuff like stale-if-error or insane client max-age headers if a client is motivated.

HTTP caches can and do serve stale content even without those "fancy" things (e.g., when the origin server is disconnected). If you're using HTTP and caching has taken place, you fundamentally need to understand how old the response you're using is if it's time-sensitive -- which this is. That means checking the Age.

> The existing draft seems to have caused a little bit of confusion by saying SHOULD match rather than MUST match.. The intent for that was to allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if you cannot figure out the DNS lifetime from your HTTP server code). The subsequent sentence enforced the >= property.
> 

It looks like you're using RFC2119 requirements to bring attention to important parts of the specification ("we really mean that this could trip you up"), rather than stating actual requirements for interoperability. These MUSTs aren't testable, and they may be too confining in some deployments. This stuff really is advice, of the "if it hurts, don't do that" sort -- not requirements.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 8 May 2018 18:25:20 +0200

On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham <[email-masked]> wrote:

>
> > This text reads more fluidly, and that is nice. OTOH it doesn't do much
> to resolve the core tension in https://github.com/dohwg/draft
> -ietf-doh-dns-over-https/issues/153. The current ID uses normative
> I forgot to say thank you for the text - I just was trying to communicate
that I think the rationale is more of the blocker for this issue than the
text. So that's what I'm trying to drill down on here..

> like to hear (here) what the issue is.

Ben and Dave pushed back in the github - it would be helpful to hear them
here as well, I agree.

>
> HTTP caches can and do serve stale content even without those "fancy"
> things (e.g., when the origin server is disconnected). If you're using HTTP
> and caching has taken place, you fundamentally need to understand how old
> the response you're using is if it's time-sensitive -- which this is. That
> means checking the Age.
>
>
This text doesn't prevent you from serving anything - it just defines how
you set the freshness lifetime so that an Age calculation at the HTTP level
actually reflects the fresh/stale status of the DNS content in a
conservative fashion. A client very concerned about that could make the
calculation or it can assume that the server did the best it could do (i.e.
its either fresh, or stale in extremis so use it anyhow) and use it once
for record types like A.

> The existing draft seems to have caused a little bit of confusion by
> saying SHOULD match rather than MUST match.. The intent for that was to
> allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if
> you cannot figure out the DNS lifetime from your HTTP server code). The
> It looks like you're using RFC2119 requirements to bring attention to
> important parts of the specification ("we really mean that this could trip
> you up"), rather than stating actual requirements for interoperability.
> These MUSTs aren't testable, and they may be too confining in some
> deployments. This stuff really is advice, of the "if it hurts, don't do
> that" sort -- not requirements.
>
>
I must be misunderstanding what you mean by not testable - the alignment of
expiration information seems pretty observable. And there is an operational
impact to terminal clients without caches (either DNS or HTTP) which simply
want to lookup a record and use it having to retry to get non-expired info
(and the rather large risk of them not trying and using old data instead).
So I guess you can argue that without 2119 language the DOH client and
server can communicate, but without normative provisions constraining the
server you can't interop well with the Internet.. seems 2119 in scope to me.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 8 May 2018 12:44:17 -0400

On Tue, May 8, 2018 at 12:25 PM, Patrick McManus <[email-masked]>
wrote:

>> > Comments from you and Martin (and this text suggestion) support
>> changing this from normative language to advice. The other comments favor
>> the more deterministic behavior we currently have.
>> >
>> > Can you help me understand the argument you are making? Martin
>> primarily suggests having the DNS code check the TTL before use rather than
>> relying on the cache to serve fresh responses - but I think that particular
>> point has met significant pushback largely from the DNS experts in the
>> community..
>>

As a standards matter, it seems to me that the DNS experts are still
working out the details of when it might be OK to go past the end of TTL
(e.g. https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-00).
Allowing DOH to violate TTL would risk pre-empting that DNS discussion.  I
think it's worthwhile for us to be conservative in what we send until
serve-stale and related DNS issues are resolved.

> I must be misunderstanding what you mean by not testable - the alignment
> of expiration information seems pretty observable. And there is an
> operational impact to terminal clients without caches (either DNS or HTTP)
> which simply want to lookup a record and use it having to retry to get
> non-expired info (and the rather large risk of them not trying and using
> old data instead). So I guess you can argue that without 2119 language the
> DOH client and server can communicate, but without normative provisions
> constraining the server you can't interop well with the Internet.. seems
> 2119 in scope to me.
>
>
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2018 17:01:18 -0700

Howdy,

Some comments in-line, thanks for the text.

On Mon, May 7, 2018 at 5:10 PM, Mark Nottingham <[email-masked]> wrote:

> I think it would be useful to specify whether we are talking only about
the upstream network caches or the local caches when using phrases like
"pass through" (the use of a local HTTP cache here by a DNS API service to
furnish data to a DNS client should either be explicitly in or out of
scope, in other words).

> I agree with other that the use of RFC 2119 language like SHOULD is
appropriate here.  We may want to allow for some variance, but a very clear
expectation will help more than "encouraged" will, at least in my opinion.

> Again, I think "Typically...will" should transition to an RFC 2119
requirement.  This may mean making it explicit that when the HTTP responder
cannot calculate the smallest TTL it should use cache-control methods to
limit caching.

> to reuse a cache entry that is no longer fresh.

I'm concerned about the use of these with responses that contain multiple
records.  If this text is retained, I think it will have to specify how to
manage the multiple record case.

> that some caches might not honour these directives, depending upon their
Should a DNS API client consider such a response as equivalent to SERVFAIL?

> I would have, perhaps naively, expected zone transfers to be the result of
POSTs rather than GETs.  Which types of results can be be retrieved by each
might be useful to lay out somewhere, just to forestall confusion like mine.

thanks,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Wed, 09 May 2018 00:22:12 +0000

I'm just glad we're having the discussion.  There wasn't a lot of debate
about this point and now it seems like it's well-litigated.  (Beyond my
tolerance, but that's OK, I have a short attention span.)

In any case, Mark's text is an improvement; with or without the use of 2119
language.  I don't like having two sources for the same type of
information, but that is the nature of the protocol we're building.

I had hoped that we could lean more heavily on DNS, but it seems like DNS
folks want to lean more heavily on HTTP mechanisms.  That's something to
reflect on, perhaps, but not worth more debate.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 May 2018 23:24:13 +0000

On May 8, 2018, at 2:45 AM, Miek Gieben <[email-masked]> wrote:
> If you only look a the TTL and not the inception and expiry dates of RRSIGs you can easily serve BAD data.

That's not how I read RFC 4033. It says:

8.1.  TTL Values vs. RRSIG Validity Period

   It is important to note the distinction between a RRset's TTL value
   and the signature validity period specified by the RRSIG RR covering
   that RRset.  DNSSEC does not change the definition or function of the
   TTL value, which is intended to maintain database coherency in
   caches.  A caching resolver purges RRsets from its cache no later
   than the end of the time period specified by the TTL fields of those
   RRsets, regardless of whether the resolver is security-aware.

   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
   the other hand, specify the time period during which the signature
   can be used to validate the covered RRset.  The signatures associated
   with signed zone data are only valid for the time period specified by
   these fields in the RRSIG RRs in question.  TTL values cannot extend
   the validity period of signed RRsets in a resolver's cache, but the
   resolver may use the time remaining before expiration of the
   signature validity period of a signed RRset as an upper bound for the
   TTL of the signed RRset and its associated RRSIG RR in the resolver's
   cache.

To me, "may use the time remaining before expiration" does not sound a requirement, or even an expectation. 

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 May 2018 23:26:32 +0000

> an expiry time you might as well do it properly.)

See my previous message about why I don't think discussion of RRSIG expiration time is appropriate for this discussion.

> draft and you probably don't want to make DoH wait for it.

Further, the early discussion of draft-ietf-dnsop-serve-stale in the DNSOP WG indicates that it is pretty contentious, and we can't predict how the discussion will come out.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 May 2018 23:31:46 +0000

On May 8, 2018, at 4:54 AM, Mark Nottingham <[email-masked]> wrote:
> It looks like you're using RFC2119 requirements to bring attention to important parts of the specification ("we really mean that this could trip you up"), rather than stating actual requirements for interoperability.

I would like to see the RFC 2119 language for security. That is, if a resolver vendor says "eh, I don't see 2119 words here so I won't implement it", their resolver will cause clients to use data that it would not have gotten if it had been using DNS-over-port-53.

> These MUSTs aren't testable,

Agree.

> and they may be too confining in some deployments.

Such as...?

> This stuff really is advice, of the "if it hurts, don't do that" sort -- not requirements.

The 2119 language being suggested is for DNS API servers, and there is no concept of "if it hurts" for them. The hurt comes to their clients. Thus, the stronger language is warranted.

--Paul Hoffman

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 May 2018 12:22:57 +1000

Sorry, I had a weekend.

I'm OK with the text that Patrick incorporated, it's not worth getting too far into the weeds here. But, to answer a question / explain where I'm coming from:

> On 9 May 2018, at 2:25 am, Patrick McManus <[email-masked]> wrote:
> 
> I must be misunderstanding what you mean by not testable - the alignment of expiration information seems pretty observable. And there is an operational impact to terminal clients without caches (either DNS or HTTP) which simply want to lookup a record and use it having to retry to get non-expired info (and the rather large risk of them not trying and using old data instead).

I don't understand how the location of the cache has anything to do with this. If a client gets a stale response -- as I said, this is very possible today despite the language in the draft -- they need to be able to deal with it. If the client wants to act like that's not a possibility, they're going to have a bad time.

> So I guess you can argue that without 2119 language the DOH client and server can communicate, but without normative provisions constraining the server you can't interop well with the Internet.. seems 2119 in scope to me.

The style of requirements used doesn't tell consumers what to do when they're violated, and -- as we've seen many times -- implementers tend to read too much into them, e.g., refusing messages which violate them, even though no such thing is specified. 

In other words, specifying in terms of ideal requirements (e.g., "the message MUST look like foo") hurts interop. It's much more effective to specify requirements in terms of producer and consumer behaviours, and to use those requirements sparingly. 

E.g., in the previous text, it said:

"""
The response freshness lifetime MUST NOT be greater than that indicated by the DNS resource record with the smallest TTL in the response.
"""

This is better stated as something like:

"""
The DNS API server MUST NOT generate messages containing DNS resource records with a HTTP freshness lifetime greater than their smallest DNS TTL. DNS API clients can retry requests when encountering messages that violate the requirement above, or use the now-stale DNS records.
"""

That said, another reason to avoid requirements here is that, as discussed, there might be future uses for stale responses, but now they'll be forbidden by something that doesn't really need to be a requirement, and so the document will have to be updated -- creating friction against these uses. This is why I prefer something like:

"""
The DNS API server should typically generate messages containing DNS resource records with a HTTP freshness lifetime greater than their smallest DNS TTL. DNS API clients can retry requests when encountering messages that violate the requirement above, or use the now-stale DNS records.
"""

The current text isn't bad, but the SHOULDs are unqualified, and IME SHOULDs like that just confuse people.

Cheers,

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 May 2018 12:15:36 +0100

> requirement, or even an expectation.

RFC 4035, section 5.3.3

   If the resolver accepts the RRset as authentic, the validator MUST
   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
   a value no greater than the minimum of:

   o  the RRset's TTL as received in the response;

   o  the RRSIG RR's TTL as received in the response;

   o  the value in the RRSIG RR's Original TTL field; and

   o  the difference of the RRSIG RR's Signature Expiration time and the
      current time.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Fitzroy: Northerly 4 or 5, occasionally 6 in southeast. Moderate,
occasionally rough. Rain at times. Moderate or good.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 May 2018 13:03:56 +0000

>   o  the difference of the RRSIG RR's Signature Expiration time and the

Ouch. (Note to HTTP folks: you're not the only ones with RFCs whose text does not always line up.)

Proposed addition:
   If the DNS API Server is also Security-Aware Resolver ([RFC4033] Section 2),
   the explicit freshness time MUST be set based on [RFC4035] Section 5.3.3.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Mon, 14 May 2018 14:15:32 +0100

> whose text does not always line up.)

I think the 4033 use of lower-case "may" is just a poor choice of
informative / descriptive vocab, and it isn't supposed to mean "MAY"
but in fact "can" or "might" (depending on context). There aren't any
normative requirements in 4033.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression