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

[Colm MacCárthaigh]

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árthaigh 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 know
> > 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.



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

-- 
Colm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160404/60594521/attachment.html>