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 a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop