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

[Andrew Sullivan]

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.  The zone administrator put the RR in there,
and he or she decided that the RRTYPE was the right one.  You're
proposing that the slave server put in checks to prevent transfers
working under the case where the slave doesn't know about that RRTYPE
even though the slave is not (by definition) in a position to evalute
the administrator's intentions and decision-making.

There are lots of people operating slave services for others, and the
master in those cases can easily be operated by someone else.  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."

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

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

> I don't think we're in the realm of reasonable disagreement here. In the
> face of reasonable scenarios where  accepting unknown record types leads to
> actual resolution failures

I haven't actually seen the "reasonable scenario" you're talking about
-- the only example was DNAME.  First, it seems like a mighty peculiar
case to optimise for; and anyway apparently the problem there is
people putting data in the master zone in a way that shows they didn't
understand what the RRTYPE did.  The approach you're advocating
requires every server in your chain to be upgraded as soon as you want
to publish a new RRTYPE; this is bad for innovation in the DNS and a
step backwards.

> , you're stubbornly advocating for a kind of lawyerly "rules must be
> obeyed" reading

I most certainly am not.  I'm saying that the approach you're arguing
for is bad for the health of the Internet, because it makes it much
more ossified.  We solve that problem years ago, and it's distressing
to see someone suggesting that we go back to that bad state of
affairs.

I think I've probably said enough on this, however, so it's my last
remark on it in this thread.

Best regards,

A

-- 
Andrew Sullivan
ajs at anvilwalrusden.com