On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski" <dnsop-boun...@ietf.org on behalf of tjw.i...@gmail.com> wrote:
I've only read briefly the drafts and see hints that issues I raise below are still lingering. There's no denying that there's a desire to solve "this". I keep in mind that this isn't the first time there's been a desire to add this to the DNS, each time more issues were raised than solutions put forth. That doesn't mean one can't keep trying, but realize this won't be easy. >- Do we want to Server to PUSH any or all Associated Answers, or This is what got DNSSEC started in the first place - the potential for servers to push data in the additional section. With DNSSEC the danger of cache poisoning is reduced but now, for out of server bailiwick answers, the client will start chasing DNSSEC trust chains, perhaps needlessly. >- Do we want the Client to PULL any or all Associated Answers, or The question I keep asking myself is: How is this different from a client just hitting a server with all anticipated questions at one time? Why not just ask for qtype ANY all the time, for data sets owned by the same domain name. Caching (shared, that is) is supposed to play a role here, keeping answers closer to the need than at the authority. (And, of course as has been mentioned in the list, does this enable amplification? I.e., just like ANY.) >- Do we want the Status Quo? For quite some years we tried to damp out special processing for types as this made rolling out new types easier with old code. The idea was to get to where "Handling of Unknown DNS Resource Record (RR) Types" was possible. I can see developing a policy for DNS responders to include other RRsets as part of the response to a question, but how is this policy made known to the querier? The querier needs to know it to decide if each other RRset is germane or a poisoning attempt. (Germane meaning, genuinely related to the question.) I can see developing a means for a client to ask for something and "whatever is relevant." That's partly done by ANY - and in fact the same issue with ANY pops up here, does a cache with part of the answer only give back that or try to get the entire answer? Will a recursive element have to track all portions of the response to a question instead of caching the sets individually? What if the TTL are set differently (on purpose)? Do we want to split the DNS protocol between what is possible on TCP and what is possible on UDP? Right now, AXFR is only available on TCP due to its design. To we want to define some "dangerous" (so to speak) queries to be only on TCP? And we have to define the semantics of how the responses are cached, tracked, etc. IMHO, if the server can let the client know what the policy regarding associated answers is, the server can push data to the client. I don't really see how client pull is better than the client asking for things in parallel.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
