Subject: [DNSOP] the root is not special, everybody please stop obsessing over it

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Feb 2019 13:57:14 -0800

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.

vixie

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Feb 2019 09:13:07 +1100

> On 15 Feb 2019, at 8:57 am, Paul Vixie <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Feb 2019 15:23:18 -0800

Mark Andrews wrote on 2019-02-14 14:13:
...
> authoritative for some zones.

i didn't expect you to need the broader example. the narrow example 
where i can't find my own zones is trivial. it's when i can't find other 
services whose dns is authoritatively served within my isp or my region, 
because even though i have connectivity within that isp or that region, 
there is a political or physical connectivity break between that isp or 
that region and the rest of the world, for example, the servers for 
TLD's and 2LD's and 3LD's whose delegators are outside my connectivity.

> named we work around this by having a also-notify clause in the zone’s

that won't help. an authority server must have a protocol by which they 
can, at their own discretion, opportunistically invalidate prior 
answers, and which can be trusted by the RDNS servers hearing those 
invalidation messages.

> this result after.  With a little bit of EDNS negotiation both can be transmitted in

that won't help the case which is more common than connectivity splits, 
which is where the old data has become harmful (key compromised, server 
or network offline, emergency renumber or rehoming or rekeying required).

let's stop thinking of this as a root problem or a TLD problem. the 
metadata an RDNS will need to reach and trust servers it can reach, may 
be on the wrong side of a network partition. that includes the entire 
NS/DS and DNSKEY/RRSIG chain, plus A/AAAA glue. we need partial zone 
authority, like a mini-slave, where the RDNS has _subscribed_ to the 
content it is keeping, and has a potential trust relationship with the 
owner of that data. we can argue about whether it's like mini-IXFR in 
which case it can answer authoritatively for the partial data it has 
leased. but we should not be talking about second TTL's, or root-only 
solutions like 7706.

vixie

-- 
P Vixie

---

From: Evan Hunt <[email-masked]>
Date: Thu, 14 Feb 2019 23:41:11 +0000

On Thu, Feb 14, 2019 at 01:57:14PM -0800, Paul Vixie wrote:
> that's near its expiration point.
[...]
> _that_ would be complexity worth its cost. 7706 was not. HAMMER is not. 

I'm confused, what's the difference between HAMMER and the thing you said?

(Which BIND also does, incidentally.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 14 Feb 2019 23:56:14 +0000

> correct operation during network partition events.

This point is well taken, but sometimes the root zone is a useful test
case for innovations that might be more generically useful later. It's
relatively small, relatively static, *XFR accessible, signed but uses
NSEC not NSEC3, etc. It's pleasantly free of annoyances.

So, zone mirroring fell out of 7706, and I suspect it will eventually have
broader applications than just local root cache. I think some of the early
work on aggressive negative caching was root-specific as well.  I wouldn't
assume an idea is bad just because it's currently focused on the root, it
might not always be.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Feb 2019 16:05:22 -0800

Evan Hunt wrote on 2019-02-14 15:56:
>> 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.
> 
> This point is well taken, but sometimes the root zone is a useful 
> test case for innovations that might be more generically useful 
> later. It's relatively small, relatively static, *XFR accessible, 
> signed but uses NSEC not NSEC3, etc. It's pleasantly free of 
> annoyances.

it's distraction value, where countries lacking root server _operators_
of their own, feel diminished thereby, and where technology solutions
that affect the root zone in some way, feel unduly relevant... makes it
an _unuseful_ test case. recall that AAAA and DS came to every other
zone in the DNS before it was grudgingly admitted into the root zone.

we have to stop using the root zone as any kind of test case. it's not
special and should be treated unspecially. any technology which focuses
on it should be suspected immediately of "shiny object syndrome."

> So, zone mirroring fell out of 7706, and I suspect it will
> eventually have broader applications than just local root cache.

nope. because it did not prototype any partial replication. i'm not
going to mirror COM because i need it to reach FARSIGHTSECURITY.COM. we
needed to focus on partial replication, and avoid any solution that
would only work for small zones that changed infrequently, so as to
avoid wasting years of opportunity on a solution that changed nothing
and led nowhere.

> I think some of the early work on aggressive negative caching was 
> root-specific as well.

no. in fact, the opposite was true. the first ANC was OTWANC (off the
wire ANC), which had to be specified as part of DLV, which was
instigated in the first place principally because noone knew how many
more years we'd have to wait before a DS RR could be placed into the
root zone.

> I wouldn't assume an idea is bad just because it's currently focused
> on the root, it might not always be.

for reasons stated above, there are _no_ counterexamples showing that a 
focus on root-specific technology ever did any good, and a plethora of 
examples where focus on root-specific technology did some lasting harm.

therefore, our assumption of any root-specific proposal should be, until 
and unless proved otherwise on a case by case basis, that it's "shiny 
object syndrome", rather than a legitimate engineering exercise.

-- 
P Vixie

---

From: william manning <[email-masked]>
Date: Thu, 14 Feb 2019 17:35:33 -0800

so, you would like the DNS to be resilient enough to "see" what was
topologically reachable and build a connected graph of those assets?  I
think that has been done, both academically and in a more limited way,
commercially, but its not called DNS so as not to upset the DNS mafia.  Or
do you want something more restrictive than that?

/Wm

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Feb 2019 17:51:45 -0800

william manning wrote on 2019-02-14 17:35:
> topologically reachable and build a connected graph of those assets?

no. that's not possible, and not desireable in any case.

> I think that has been done, both academically and in a more limited way, 
> commercially, but its not called DNS so as not to upset the DNS mafia.  
> Or do you want something more restrictive than that?

i want the metadata i need to reach and trust assets on my side of any 
connectivity loss event, to be kept in warm storage, and made subject to 
trusted invalidation on an opportunistic basis, at the discretion of the 
authority operators who own the data i have warm copies of.

in practice this means DS/NS and DNSKEY/RRSIG and AAAA/A from my static 
trust anchor(s) down to any data i used recently or frequently (or by 
some other priority scheme), and i want it to look a bit like the single 
transaction mode of IXFR plus the single transaction mode of NOTIFY.

no topology information as to actual connectivity will be modeled or 
estimated or needed. what matters is whether i can still reach all 
internet resources on my side of a break in connectivity (whether local 
or regional or distant), without needing any information that's 
otherwise only available on the far side of the connectivity break.

thanks for asking; i am happy to clarify. DNS infrastructure should not 
be centralized, even if its content remains centrally coordinated by 
ICANN. (block chain people keep telling me that ICANN will be obsolete, 
but i'm not taking a position on that, only on data resiliency.)

-- 
P Vixie

---

From: Grant Taylor <[email-masked]>
Date: Thu, 14 Feb 2019 19:27:41 -0700

> authority operators who own the data i have warm copies of.

Please explain how "warm storage" relates to priming issues.  Does warm 
mean that it's something you have queried?  Or does it also include 
pertinent (meta)data for interesting things (but not everything) that 
you've not yet queried?

> otherwise only available on the far side of the connectivity break.

Does "still reach all internet resources on my side of the break" 
include things that you've not yet queried for?

I'm wondering if a fancier cache of some sort would suffice.

Specifically I wonder if BIND (et al) can maintain a FIFO (like) list of 
QNAMEs, moving the current QNAME to the start of the list, and 
proactively refreshing the first 10 / 100 / 1000 / pick a number in such 
a way as to not alter the list position when refreshing.

This obviously has a priming problem as a QNAME won't be subject for 
refresh until /after/ it has been queried the first time.  This is why I 
question your use of the word "warm".

Perhaps this can be implemented as part of the existing garbage 
collection process that remove expired cache entries.  If the data to be 
purged is in the FIFO, then refresh it and cache the results without 
moving it to the head of the FIFO.

The other thing that I might add to this is something to artificially 
prime the cache by querying for specific names off of a user definable list.

How close would something like this be to what you're wanting to see?

This would re-use existing mechanism and methodology.  It wouldn't see 
changes in data until after cache expiration.  But this is SoP for 
caches now.

-- 
Grant. . . .
unix || die

---

From: william manning <[email-masked]>
Date: Thu, 14 Feb 2019 18:48:26 -0800

You are welcome.  I think, modulo minor differences in terminology, we are
saying pretty much the same thing.
pragmatically, DNS infrastructure dependencies can not be maintained and
work on data resiliency is where the useful work lies.

/Wm

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 Feb 2019 18:56:51 -0800

Grant Taylor wrote on 2019-02-14 18:27:
> Please explain how "warm storage" relates to priming issues.  Does
> warm mean that it's something you have queried?  Or does it also
> include pertinent (meta)data for interesting things (but not
> everything) that you've not yet queried?

i don't expect anyone to store anything they have not queried, though
it's natural for an implementation to permit an operator to statically
define other targets as well, much as mark andrews did with "stub" zones
starting in 1990 or so in BIND4.

> include things that you've not yet queried for?

no. while there may be some kind of persistent storage of long term
popularity information so that things that were ever warm can be kept
warm even if not queried since the last reboot cycle, i do not expect
any tree-walking exercises. my long term study of RDNS tells me that
there is a high correlation between past and future queries. if some
query tries to occur during a connectivity break, it might fail, and in
that sense it's a DNS problem we've always had, that i'm not solving.

> How close would something like this be to what you're wanting to

i think leasing behaviour is expensive on a network-wide basis, and
should be limited to high-value data, by which i mean metadata needed to
reach and trust name servers. so, DS/NS, DNSKEY/RRSIG, and related
AAAA/A. i do not foresee remembering non-metadata information, no matter
how popular, since it's in a content operator's power to put a copy of
their DNS infrastructure inside any region that also has a copy of its
services. it's only third party metadata, like the delegation and trust
chain, that is an unmanageable risk today.

also note, i would not propose invalidation on its own merits, because 
the cost of the data-state and trust-state is too high. however, if we 
have to maintain that state anyway, for leasing, then invalidation is 
approximately free, depending on the priorities of the authority server 
operator. therefore, it becomes a package deal, one stone, two birds.

-- 
P Vixie

---

From: Evan Hunt <[email-masked]>
Date: Fri, 15 Feb 2019 04:21:47 +0000

On Thu, Feb 14, 2019 at 04:05:22PM -0800, Paul Vixie wrote:
> going to mirror COM because i need it to reach FARSIGHTSECURITY.COM.

I didn't say anybody's going to mirror COM, I said I suspect zone
mirroring will find applications other than pre-caching the root.
The fact that it isn't a complete solution to the problem space you're
interested in at the moment doesn't mean it was useless. That wasn't a major
motivation for the work anyway, I don't believe -- my recollection is that
it was mainly about reducing garbage traffic, with latency reduction for
some resolvers a happy side-effect.

Keeping cache data warm and available during network partitions is a
largely solved problem; we have prefetch/hammer, we have serve-stale.
(Also apparently we have whatever generates all that zombie DNS traffic
Geoff discovered back in 2016, but I'd rather avoid perpetuating that
mistake, which seems *quite* perpetual enough as it is.)

Keeping cache data coherent is less solved: we don't have the trusted
invalidation piece you mentioned. I agree that might be a useful line of
inquiry.  I guess that's the point you were trying to make; I didn't get
it immediately because you started off discussing the shortcomings of an
RFC that doesn't seem particularly directly related.  So let's get
specific about the problem and discuss requirements for a solution.

---

From: David Conrad <[email-masked]>
Date: Thu, 14 Feb 2019 21:51:42 -0800

Paul,

On Feb 14, 2019, at 1:57 PM, Paul Vixie <[email-masked]> wrote:
> 7706 is wrong headed on a number of levels, but its worst offense is to think that the root zone is special.

Operationally, the root zone actually is special. It is, after all, the starting point of the name space. As far as I can tell, there are 3 ways the root zone is special:

1. How does one obtain name servers for the root zone? How does one obtain name servers for any other zone?
2. Who controls the name servers for the root zone? Who controls the name servers for redbarn.org?
3. What happens if the root zone is unreachable? What happens if redbarn.org is unreachable?

7706 describes one method to improve resiliency, performance, and privacy of root name service, with no modification of the DNS protocol or name servers. It is, of course, possible to do the same thing with any zone, assuming you have enough memory, but few zones generate sufficient interest to do so. Not sure why you’re arguing against it. Could you explain?

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Fri, 15 Feb 2019 09:47:49 +0000

Paul Vixie <[email-masked]> wrote:

> unbound has pioneered a bit of this by automatically refetching data that's
> near its expiration point.

BIND also does this, it's on by default.

I'm not a fan of RFC 7706 because I think it's redundant wrt prefetch
(HAMMER), NXDOMAIN synthesis, and (to a much smaller extent) serve-stale.

> 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.

We have local stealth secondary copies of our zones on our recursive
servers which helps to some extent, except when downstream validators want
to get the chain of trust. But serve-stale should help.

I wonder if it's worth having different prefetch logic for infrastructure
records (NS, DS, glue, etc) to more eagerly keep them warm than leaf
records.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Northwest Southeast Iceland: Northeasterly 5 or 6, becoming variable 3 or 4.
Rough. Wintry showers. Good, occasionally poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2019 10:59:36 +0100

On Thu, Feb 14, 2019 at 01:57:14PM -0800,
 Paul Vixie <[email-masked]> wrote 
 a message of 42 lines which said:

> 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.

I agree that this is an issue (as you said, the simple case of "my own
zone" is easily solved by stub and/or forward zones in BIND) but any
solution must take care of phantom domains. If I register
malware-c-and-c-as-a-service.com and it's taken down, the solution
should not make this domain to work after. (Except of course for
resolvers who decided to configure a stub zone for this domain.)

---

From: Bob Harold <[email-masked]>
Date: Fri, 15 Feb 2019 09:29:29 -0500

> resolvers who decided to configure a stub zone for this domain.)

I think in most solutions, if the name servers for "
malware-c-and-c-as-a-service.com" and "com" are both unreachable, the
domain should continue to resolve.  But if "com" is reachable, and says "
malware-c-and-c-as-a-service.com" no longer exists, it should go away.

-- 
Bob Harold

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 15 Feb 2019 15:34:46 +0100

On Fri, Feb 15, 2019 at 09:29:29AM -0500,
 Bob Harold <[email-masked]> wrote 
 a message of 73 lines which said:

> malware-c-and-c-as-a-service.com" and "com" are both unreachable,
> the domain should continue to resolve.  But if "com" is reachable,
> and says " malware-c-and-c-as-a-service.com" no longer exists, it
> should go away.

Any volunteer to write a problem statement for the "VIX.SU issue"?
Short version: "when I'm on the same network that at least one
authoritative name server of VIX.SU, I want this domain to work, even if there
is zero Internet connectivity to the outside world" Longer version:
"TODO (think of: is it automatic or not, does it require prior access
or not, phantom domains, etc)"

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Feb 2019 08:39:13 -0800

> to get the chain of trust. But serve-stale should help.

prefetching or leasing or rrset subscription is expensive when viewed 
from the dns-at-large perspective. we ought to prioritize the 
information we will need most in the event of a network partition. and 
the idea that an operator would have to predict where a partition could 
take place, and add stealth secondaries for the things they know about, 
is wrong in two ways. it's too much work, and never enough benefit.

> records (NS, DS, glue, etc) to more eagerly keep them warm than leaf

yes, it obviously is, but only if you intend to use them even if the 
authority for some of your data is at that moment not reachable. so, 
serve-stale and hammer attempt to solve the wrong problem. if you're 
going to use something the way a stealth slave would do, you've got to 
ask the authority's instructions, and be capable of hearing and trusting 
NOTIFY events when that data changes for any reason.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Feb 2019 08:44:18 -0800

>> and says " malware-c-and-c-as-a-service.com" no longer exists, it

this is why serve-stale is most wrong. permission, and an agreement to 
hear a trusted NOTIFY later if the authority wants to do the work of 
keeping track of who it told things to, and the work of telling them 
when something has importantly changed (like a glue address change, a 
name server change, a key change, a signature invalidated, or malware 
removed). this is a subscription (leasing) problem, not a caching one.

> or not, phantom domains, etc)"

just as root-level is the wrong focus, so is local-level. the reason we 
don't solve this problem with multicast NOTIFY is that the information 
you may need a subscription to (due to potential network partitioning) 
could be in another campus, or another region, or another isp, or 
another country.

-- 
P Vixie

---

From: william manning <[email-masked]>
Date: Sat, 16 Feb 2019 10:00:55 -0800

Multicast NOTIFY?  You mean like RFC 6804, or RFC 7558.  Use of a
subscription model or lease still depends on reachability and when you
don't have that, you have two choices, use a stale lease or abandon it.
Take your pick.

/Wm