[dns-operations] TTL=0

[m3047]

Andrew, I don't think that RFC addresses the problem.

Let me frame it this way: if you're not the authoritative source, then why 
are you sending me something with a TTL of zero: hasn't it expired? I 
suspect that this logic is behind the observed fact of SOA TTLs seldom 
being zero in practice.

In practice, many requests from the application layer for a particular 
FQDN may happen in short order (a web browser loading assets other than 
Magecart for example <-- joke! but anyway assets coming from the same 
server as the base page). The performance of having to refetch a TTL=0 
record in some circumstances may not be acceptable. Perhaps the 
application treats the entire page (I'm using "page" to allude to the 
process of building the presentation of a web page, but this artifact 
doesn't have to be a web page and its atomicity or lack thereof is what I 
refer to) as a "transaction" in some fashion, and anticipates that 
repeated requests will yield different answers and wants to avoid that.

Anybody who doesn't understand that CNAME chains exist probably hasn't 
used S3 the way Amazon intended (notionally CNAME chains are a bad idea, 
and a lot of people don't follow Amazon's doc to the letter. whether or 
not they know they're doing this I leave as an exercise for the reader). 
Resolving CNAME chains can take a non-negligible period of time. Is 
resolving a CNAME chain atomic from the POV of the requester? What about 
when it spans zones? What if part of the chain expires while it's being 
processed?

In a nutshell, sometimes things just stop working when records with a TTL 
of zero show up, leading to restarting applications, reopening network 
connections, or flushing cache.

I suspect not enough testing is done with TTL=0 in other than nontrivial 
situations and I'm not sure that it's universally straightforward to set 
up test conditions with COTS DNS software.

(I'm also not sure that "illegal" should ever be used in the context of 
DNS and RFCs, even though a DNS RFC is the only case I'm aware of where an 
RFC has suggested capital punishment for violations. In my experience 
moral outrage doesn't fix software, nor does it result in robust 
implementations; hence not all implementations may strictly follow any 
RFC in the simple pursuit of software that works in the opinion of the 
implementers.)

--

Fred Morris, internet plumber

--

# dig dns-oarc.net soa

; <<>> DiG 9.8.3-P1 <<>> dns-oarc.net soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6100
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 8

;; QUESTION SECTION:
;dns-oarc.net.			IN	SOA

;; ANSWER SECTION:
dns-oarc.net.		120	IN	SOA	ns.dns-oarc.net. 
admin.dns-oarc.net. 2018121938 300 60 604800 3600

;; Query time: 246 msec
;; SERVER: 10.0.0.220#53(10.0.0.220)
;; WHEN: Sat Jan 19 08:43:44 2019
;; MSG SIZE  rcvd: 329

# dig @ns3.dns-oarc.net dns-oarc.net soa

; <<>> DiG 9.8.3-P1 <<>> @ns3.dns-oarc.net dns-oarc.net soa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51417
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;dns-oarc.net.			IN	SOA

;; ANSWER SECTION:
dns-oarc.net.		120	IN	SOA	ns.dns-oarc.net. 
admin.dns-oarc.net. 2018121938 300 60 604800 3600

;; Query time: 187 msec
;; SERVER: 77.72.225.243#53(77.72.225.243)
;; WHEN: Sat Jan 19 08:44:02 2019
;; MSG SIZE  rcvd: 75

On Fri, 18 Jan 2019, Andrew Sullivan wrote:
> 
> Seems to me RFC2181 already answered this years ago.
> -- 
> Andrew Sullivan
> Please excuse my clumbsy thums.
>
> On January 18, 2019 17:21:40 Greg Choules <gregchoules at googlemail.com> wrote:
>> Hi Fred.
>> No, I am not talking about dscacheutil or any particular client software. I 
>> just want to know whether, in the opinion of the world's DNS professionals, 
>> recursive servers should or shouldn't ever send answers from cache with 
>> TTL=0.
>> 
>> cheers, Greg
>> 
>> On Thu, 17 Jan 2019 at 23:15, m3047 <m3047 at m3047.net> wrote:
>> Who cares about the RFC? In practice, SOME caching resolvers (and that's
>> being charitable) WILL answer with TTL=0. I've had to live with PFSense
>> deployments which did this.
>> 
>> Which in turn leads to things like (for Mac users):
>> 
>> dscacheutil -flushcache
>> 
>> Is that what you're talking about?
>> 
>> On Thu, 17 Jan 2019, Greg Choules wrote:
>>> [...]
>>> 
>>> Is there ever a case, for cached answers, that the recursive server would
>>> answer the client with TTL=0? Or would that be illegal? RFC1034 states 
>>> that
>>> records with TTL=0 "should not be cached". Note "should" and not "must".
>> _______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-operations mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations