Re: [DNSOP] Again about refuse ANY and HINFO

[Ted Lemon <[e-mail]>]

One point about repeated queries is that on the list of problems we have in
the DNS, this probably isn't high.   What would the packet rate be for such
queries as opposed to the other problem queries we see?   (I tend to agree
with your take on this generally, Ed.)

On Thu, Apr 7, 2016 at 10:32 AM, Edward Lewis <[e-mail]>
wrote:

> I've shuffled my feet before (the "Again" in the subject) to express my
> dislike of the HINFO technique.  This time I dove a little deeper into why
> I dislike the approach, motivated by something quickly said in the DNSOP
> meeting yesterday.
>
> If nothing else, I suggest that this not be standards track due to
> interoperability concerns with private key sharing.
>
> (The draft :-
> https://www.ietf.org/archive/id/draft-dnsop-refuse-any-00.txt)
>
> The draft says "the operator of an authoritative DNS server might choose"
> and proceeds to propose solutions that involve what belongs to the zone
> administrator.  Architecturally, this bugs me.
>
> The draft proposes that a server (and I'll hand wave over details that are
> in the draft for the sake of brevity in email) respond with "some other
> record" at the QNAME or, if it chooses, a synthesized HINFO record.  With
> DNSSEC, one would need to sign the synthesized record.
>
> Notably missing is - what if the QNAME does not exist ("Role of Wildcards
> in the DNS" section 2.2)?
> (An open question...)
>
> If the server chooses to answer with "just some record" (the first
> option), how would a querier know that this means ANY is not honored?
> Personally, I don't think that a protocol should have a state in which the
> situation is ambiguous.  (There are many examples of protocols that do and
> many examples of ambiguity, but that doesn't make it a good thing.)  I
> can't quantify why this approach seems to lacking something
> (architecturally).  Perhaps, if you mean "no" say "no."  Or maybe passive
> aggressive is not a good personality trait for a protocol.  I don't know.
>
> If the server chooses to answer with a synthesized HINFO and has to sign
> it for DNSSEC, there's a line being crossed.  The server answering has to
> have the zone's key to make the signature.  DNSSEC was not designed for
> that although it is easily demonstrated that on-line signing can be done.
> The reason I raise this is, what about interoperability?  ("What about the
> children?" as per https://en.wikipedia.org/wiki/Think_of_the_children)
>
> The draft doesn't address how one operator can opt out of ANY answers if
> the zone administrator does not share the keys with the operator.  In
> examples existing today, so far as I know and I could be wrong, the live
> implementation is an "owner/operator", that is an organization that plays
> the role of zone administrator (on behalf of others) and the exclusive DNS
> operator for those zones.
>
> There is nothing wrong with that set up, I'm just being specific about
> "why it works" in the field yet I see an architectural challenge.
>
> I am not criticizing the desire to opt out of ANY queries.  I have been in
> position where I wanted to do the same thing.  My discomfort lies in using
> the "data plane" to signal though.
>
> I agree this is an server operator thing, not a zone admin thing.  The
> data in the DNS is managed by a zone admin, not the server operator.  (See
> how the root zone responsibilities are divided for an example.)
>
> If nothing else, this perhaps should not be standards track.  Experimental
> or informational perhaps.  This approach is implementable, it is what an
> operator does today.  It addresses a need.
>
> But I see interoperability holes in the approach.
>
> I do know of another operator that has turned off ANY queries.  They did
> it by sending nothing back.  The name exists, the authoritative server
> sends back RCODE=refused.  As far as I know, that operator has not made
> public statements about this, I discovered it in some code I run.  Because
> of the way it answered, it was obvious that I needed to stop sending ANY
> queries to get the data I sought.  Hard fail can be good.
>
> The draft does address this:
>
> "Alternative proposals for dealing with ANY queries have been discussed.
> One approach proposed using a new RCODE ... resolvers receiving an unknown
> RCODE caused them to re-send the same query to all available authoritative
> servers, rather than suppress future such ANY queries
>    for the same QNAME."
>
>
> I see this as a tradeoff.  Extra queries versus having to reply on
> distributing a DNSSEC private key to Internet-exposed servers.  To me, in
> my opinion, for the sake of interoperability the option costing extra
> queries seems more desirable than having to figure out how to allow server
> operators share a zone admin's private key.
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>