Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Edward Lewis write
s:
> On 8/16/16, 08:57, "DNSOP on behalf of Tim Wicinski" <[e-mail] 
> on behalf of [e-mail]> 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.

You can chase chains when the client requests the data.  DNSSEC validation
doesn't need to always be done when the answer is received.

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

We have solutions to amplification.  It isn't a boggie man.

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

Unknown RRs is designed to allow data to get to the client without
*requiring* intermediate servers to know the data content.  The
key word there is requiring.

There is nothing about not specifying additional section rules.  In
fact additional section rules are officially acceptable for unknown
types.

Additionally Unknown RRs expects servers to learn about new types.
Just they that knowledge isn't supposed to be a blocker.

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

Stub clients presumably know or they wouldn't be asking for the type.

Recursive servers learn what to expect over time.  If it is signed data
they can just store it and validate it when requested.

> 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)?

Perfect is the enemy of good enough.  Servers need to learn about new
types.  They just don't need to learn immediately.

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]