Subject: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

From: Edward Lewis <[email-masked]>
Date: Sun, 13 Nov 2016 07:27:35 +0000

https://www.ietf.org/id/draft-fujiwara-dnsop-resolver-update-00.txt

Why can't a cache store the trustworthiness [RFC 2181] as metadata for the RRset, instead of having another cache?

I understand why now we don't want one set to clobber the other, that being "because of abuse."  Back in the day I was taught that the parent was authoritative for the left hand side of the NS set (the owner name) and the child was authoritative for the right hand side (the RDATA holding the name server).  That is why DNSSEC signs the child but not the parent NS copy set.

What is gained beyond suggesting resolvers reduce the child NS TTL to that of the parent TTL (if the child TTL is longer)?

Maybe this - I have seen cases where the child won't answer with its NS set but will answer the query for a name in the zone, which works if the parent NS set is used, along with the glue.  (Such a setup is broken, but the URL with the name is listed in a web site ranking tool therefore it works.)  I've seen these situations work when I use a fully functional, general purpose DNS recursive server but not if I try to descend the tree manually, the tool must be retaining the parent NS set.  (Still I don't see the need for multiple caches.)

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 14 Nov 2016 03:27:20 +0100 (CET)

Ed,

----- Original Message -----
> From: "Edward Lewis" <[email-masked]>
> To: "dnsop" <[email-masked]>
> Sent: Sunday, 13 November, 2016 08:27:35
> Subject: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

> RRset, instead of having another cache?

I think think this is a technical detail best left to the software vendors
and it should be removed from the draft.

As a side note, having a (platform-sized) pointer for each RR in the RR-cache
is a huge bloat...

> I understand why now we don't want one set to clobber the other, that being
> "because of abuse."  Back in the day I was taught that the parent was
> authoritative for the left hand side of the NS set (the owner name) and the
> child was authoritative for the right hand side (the RDATA holding the name
> server).  That is why DNSSEC signs the child but not the parent NS copy set.

If we were to design RFC1034/1035 again I would say that NS records are more
close to DS.

> What is gained beyond suggesting resolvers reduce the child NS TTL to that of
> the parent TTL (if the child TTL is longer)?

The predictability of resolver behavior.  As I said in one of my previous replies,
you are not guaranteed that the child NS will ever reach the resolver when answer
minimization is in effect.  And what exactly happens when the NS records expire?
It depends - is the resolver prefetching, so it still knows the existing
nameservers - possibly pulling the child NS in this TTL round? Or did it expire
completely and the resolver has to start from bottom - just pulling only the
parent nameservers again?

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------