On 4/3/17, 16:00, "DNSOP on behalf of Paul Vixie" <dnsop-boun...@ietf.org on behalf of p...@redbarn.org> wrote:
On Monday, April 3, 2017 7:48:49 PM GMT Paul Wouters wrote:
> ...
> As Evan said, there should not be any code in an authoritative server
> that requires it to do recursive validation.
I'm going to squat on Paul Vixie's subject line but not respond to anything he
says, in part because something crossed my mind, based, ironically enough, in a
conversation Paul and I had not long ago (at an ICANN meeting venue).
We reminisced about client-subnet-id. There was a way-back time when I spoke
of a q-trinity - qname, qtype, qclass - being the three things needed to get a
specific response from DNS. Including any other information was a pollutant.
Paul pulled that out when my name was on an early version of the
client-subnet-id document (as a caretaker editor). The reason I was
participating in that was seeing how the implementation of "stupid DNS tricks"
(as one side of the war might call them) or "tailored DNS responses" (as the
other side of the war might call the same battle) got carried out in specific
contexts. They "worked" despite some flaws and dire predictions.
It isn't that it's a sin to pollute the query with other information, there's a
cost of doing so. In some cases, the cost is worth the benefit, in others,
not. It's not a binary "do it or not" but a sliding scale of "is the cost less
than the benefit?" I say sliding because "cost" and "benefit" are not fixed
values over time. (Moore's law, Kaminsky's BlackHat presentation change cost
and benefit calculations.)
Back to the quote above. In general, an authority server having to do lookups
will have scaling implications, suck performance, present a potential for
abusive loading (think DoS/DDoS). (Related but different, DNSSEC once required
the server verify signatures on load - that slowed loading zones, so it was
dropped with the consequence of having to carefully define the AD bit in a
response.) But in specific, managed and contained contexts, having authorities
look up data to improve an answer can be worth the cost.
Question hard-and-fast rules from the past. Things change.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
