> On 15 Feb 2019, at 8:57 am, Paul Vixie <p...@redbarn.org> wrote: > > 7706 is wrong headed on a number of levels, but its worst offense is to think > that the root zone is special. we need dns to have leases on its delegation > chain including glue and dnssec metadata. everything you might need to use in > order to reach a zone authority and trust its results should be kept warm. > the owner of the data you've leased must have the ability to reach out and > invalidate it in a trusted way. > > having .CN's delegation data resident because of 7706 doesn't help you reach > your own EXAMPLE.CN name servers if the network outage you were concerned > about is inside china rather than between china and the rest of the world. > > NFS gave an example of how to solve this, 25 years ago, with NQLEASE. i am > not asking for new computer science, only application of what's already well > understood outside the DNS community, as to keeping the hot side hot. > > unbound has pioneered a bit of this by automatically refetching data that's > near its expiration point. we should work from there outward, by > standardizing it, prioritizing delegation and dnssec metadata, and exploring > ways that the .CN servers could invalidate old NS RRset or DS RRset data (or > indeed DNSKEY and RRSIG) if it was willing to do the work of remembering who > it had handed the now-invalid data to and what trust markers would be needed > to get an RDNS to accept some new form of NOTIFY to purge its cache. > > _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. > indeed nothing which treats the root zone as special is worth pursuing, since > many other things besides the root zone are also needed for correct operation > during network partition events. > > the fact that i have to hotwire my RDNS cache with local zone glue in order > to reach my own servers when my comcast circuit is down or i can't currently > reach the .SU authorities to learn where VIX.SU is, should not only concern, > but also embarrass, all of us.
Having the local recursive server having a copy of the local zones was always part of DNS’s deployment model. Having authoritative servers not be recursive servers is not the same as recursive servers not being authoritative for some zones. One thing we missed when adding NOTIFY was adding a NOTIFY-ALSO RRset. In named we work around this by having a also-notify clause in the zone’s configuration clause. DNS RRsets need two TTLs. 1) refresh after in case we need to update. 2) stop believing this result after. With a little bit of EDNS negotiation both can be transmitted in a response. > vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
