[dns-operations] unknown rrs and xfr (was Re: Recommended zone serial number format for over 100 changes / day)

[Mark Andrews]

In message <CAAF6GDd7STqF8k5gV0XbKt+Jbwz5BYt5jS_2fYgN83=rXKuyVg at mail.gmail.com>, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writ
es:
> 
> On Mon, Apr 4, 2016 at 12:36 PM, Andrew Sullivan <ajs at anvilwalrusden.com>
> wrote:
> 
> > On Mon, Apr 04, 2016 at 11:16:50AM -0700, Colm MacC=C3=A1rthaigh wrote:
> > >
> > > I don't interpret either RFC as a command to treat unknown RR-types as
> > > something that must be agnostically passed around, even if you don't kn=
> ow
> > > how to handle them
> >
> > If you are a slave, you have approximately no reason to claim that you
> > know better than the master that you're slaving from what the contents
> > of the zone ought to be.
> 
> 
> You have every reason to claim that you know what record types you
> understand and can confidently serve though.
> 
> There are lots of people operating slave services for others, and the
> > master in those cases can easily be operated by someone else.
> 
> 
> Exactly.
> 
> 
> > Adding
> > a requirement that zone transfers only succeed when the slave knows
> > about the RRTYPE basically recreates the condition that RFC 3597 was
> > created to solve: we need to be able to deploy new RRTYPEs without the
> > precondition being, "Upgrade every server and resolver in the
> > universe."
> >
> 
> I didn't invent the requirement and I'm not adding it; DNAME and DNSSEC are
> the precedent - and they only work when you upgrade the servers. They break
> when you don't. Future RRtypes may repeat this, so it's good and sensible
> operations to accommodate that.

And that does not require the slave to not accept unknown record
types.  Stop fixating on having the slave not accepting unknown
records.  It isn't the way to solve the issue.  I have already
supplied you with a alternative mechanism which will work if we
ever get to the state of needing it and it doesn't ossify the
protocol.

B.T.W.  Having signed zones served by non DNSSEC aware servers
doesn't cause major issues as long as there is at least one DNSSEC
aware server running.  Non validating clients don't care and
validating clients just re-try with a different server.  If all the
DNSSEC aware servers are down then the client doesn't get a answer
it can accept.

DNAME is only a issue for QNAMEs under the DNAME.  We survived the
introduction of DNAME w/o the sky falling.  Yes, we thought about
DNAME being served by non-DNAME aware servers yet still went ahead
with the protocol extension.

Part of the job of the expert approving code points is to think
about issues like this and push back when appropriate.

> > >, or to stop serving a zone that is handling traffic.
> >
> > The expire time _absolutely is_ an instruction that you stop serving
> > the zone if you can't show you have a current zone by then.  You're
> > supposed to SERVFAIL, and the idea that anyone would even think about
> > doing something else alarms me greatly.
> >
> 
> o.k - a lot of folks use rsync and even proprietary protocols for
> standardizing zone data; it's pretty commonplace not to delete what may be
> production critical data simply because an update mechanism has been
> failing. Beyond saving disk space, there's really no benefit either - it's
> all downside; you might cause an outage. There's no sense in that.
> 
> 
> > > it's valid to serve stale zones (dns is eventually consistent) and it's
> >
> > It's only eventually consistent if people follow the rules about
> > letting things expire when they're told to.  Otherwise, it's
> > potentially never consistent.
> >
> 
> A "SERVFAIL" because a network path broke (say a firewall) isn't
> consistent.
> 
> --=20
> Colm
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org