Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

[Andrew Sullivan <[e-mail]>]

Hi,

On Wed, Mar 23, 2016 at 09:37:57AM -0700, Marek Vavruša wrote:
> >     1.  We had no idea what resolvers who weren't expecting the AAAA
> >     in the Answer section would do.  This draft says what is "more
> >     likely", but I have no way of evaluating that claim.  Without an
> >     EDNS0 signal, I think this proposal is pretty dangerous.
> 
> 
> We have a way of measuring DNSSEC algorithms penetration, QNAME
> minimisation-enabled resolvers etc., thus also a way to evaluate this
> claim. I'm setting up a special domain using this I-D and then we can use
> RIPE Atlas or 1x1 test, should Google or someone be interested in testing
> this.

I don't understand how it's a way to evaluate this claim.  DNSSEC
includes a bit (DO) that says you're prepared to handle the additional
data in the answer section.  Indeed, the unpreparedness of people for
this data was just exactly the reason for the DO bit.  What isn't
clear to me is whether people implemented that as, "Take whatever
comes in the answer even if you didn't ask for it," or whether they're
looking for DNSSEC data.  The latter is what DO says one is prepared
to do.

> >     3.  This amounts to special server-side processing, and there'd
> >     been a traditional resistance to
> 
> I'm happy to back this with patches.

That _you_ can produce the code is not the question.  The question is
whether people are comfortable adding additional server side
processing to the protocol.  It's always been a big deal before (which
is part of the reason RRTYPEs that require this aren't eligible for
allocation by expert review).  I confess I'm susprised that this
aspect of your proposal isn't getting more push back, but maybe that's
because it's supposed to be optional.

> With all respect, I'm not in a position to be an IETF librarian.

No, but I observe you're not the only author on this document, and
since I was Olafur's co-chair when we dealt with this kind of proposal
last time I sort of assumed his memory would be as good as mine.

> If it's coming back then it means the idea is probably interesting,

There was never any question that the idea has some value.  The
question was always whether it would work reliably on the Internet we
have.  Maybe what we're saying is either (1) the Internet has in fact
changed or (2) that we're going to have to abandon some of the old
functionality.  If so, ok, but we ought to say so explicitly.  (Also,
without some significant changes to the charter and maybe to the area
in which this WG lives, I'm not sure this WG is in fact the right
place for fundamental changes to assumptions about the protocol
functioning.  Minor maintenance, sure.  Note that I don't want to play
charter games -- I think they're useless and boring -- but this kind
of major change to the protocol doesn't obviously fit to me under the
provisions in 5 of the DNSOP charter, though this is the right place
to start the discussion.  The same, note, is true of the
deprecate-classes discussion.)

> Talking to upstream is the most expensive operation for resolver
> next to signature verification.

So, yes.  It strikes me, however, that if that's the real use case you
could definitely use EDNS0, on the assumption that the end client
could use happy eyeballs.  The resolver would of course get two
queries, but it would only need to send one and could re-use the
single answer it gets over and over, meaning that cache re-use ought
to be pretty good.  

> I admit I'm not a big fan of EDNS, but I'm okay with using it if I'm proven
> that resolvers will panic
> on a sight of different record in any of the packet sections.

This is putting the burden of proof in the wrong place.  You're
proposing to change the protocol behaviour in a pretty fundamental
way.  You need to be able to show that the new behaviour doesn't break
old-but-conforming implementations.  That's how standards work.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]