[DNSOP] Again about refuse ANY and HINFO

[Edward Lewis <[e-mail]>]

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.