Re: [DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt

[Paul Vixie <[e-mail]>]

> Ralf Weber <mailto:[e-mail]>
> Friday, March 06, 2015 2:33 PM
> Moin!
>
> On Fri, Mar 06, 2015 at 01:51:53PM -0800, Paul Vixie wrote:
>> that's a big "if". here's another: if your diagnostic tools can use some
>> method other than "dig" to do your debugging for you, then, again, you
>> don't need ANY. those are two very big "if"'s.
> I can answer them with yes, so I think I'm good. I do need dig for lots
> of stuff, but not to find out what records at a give node my resolver
> has.

my point being, "deprecate it because i have alternatives i can use"
does not meet the use case of "many other people may be using dig-based
diagnostics and we should try not to completely invalidate their
approach if there's a low-hanging alternative."
>
>>>  I would like to see it deprecated to
>>> the level that no one relies on the query being answered with a record.
>> me too. that's why i'm saying, ACL, default "nobody".
> ACL is something application specific.

no. for example, see RFC 2136:

8 - Security Considerations

   8.1. In the absence of [RFC2137] or equivilent technology, the
   protocol described by this document makes it possible for anyone who
   can reach an authoritative name server to alter the contents of any
   zones on that server.  This is a serious increase in vulnerability
   from the current technology.  Therefore it is very strongly
   recommended that the protocols described in this document not be used
   without [RFC2137] or other equivalently strong security measures,
   e.g. IPsec.



or, earlier in that same document:

   3.3 - Check Requestor's Permissions

   3.3.1. Next, the requestor's permission to update the RRs named in
   the Update Section may be tested in an implementation dependent
   fashion or using mechanisms specified in a subsequent Secure DNS
   Update protocol.  If the requestor does not have permission to
   perform these updates, the server may write a warning message in its
   operations log, and may either signal REFUSED to the requestor, or
   ignore the permission problem and proceed with the update.

   3.3.2. While the exact processing is implementation defined, if these
   verification activities are to be performed, this is the point in the
   server's processing where such performance should take place, since
   if a REFUSED condition is encountered after an update has been
   partially applied, it will be necessary to undo the partial update
   and restore the zone to its original state before answering the
   requestor.

   3.3.3 - Pseudocode for Permission Checking

      if (security policy exists)
           if (this update is not permitted)
                if (local option)
                     log a message about permission problem
                if (local option)
                     return (REFUSED)


i'd appreciate not having to argue about whether the term "ACL" is one
of art or one of practice. let's talk about what we're trying to
accomplish in terms of protocol revision, rather than talking about what
specific application-specific words we shouldn't use when describing
those accomplishments.

obviously ACL is a BIND term, but unbound and nsd (and ans and cns) have
equivilents, and i don't expect any implementer to say "i don't call it
an ACL, therefore any discussion about the protocol change must not use
the term ACL." that would be a huge waste of time, similar to the time
i'm wasting writing this paragraph.

>  There may be applications that
> may want to have a default behavior, thus we should not put ACL in the
> draft.

i don't understand this statement. make the default "nobody". i thought
you were disagreeing?

>  The only thing to define in the draft is to what a requester
> can expect when issuing a ANY query.

the draft should define what a requester will hear if they ask an ANY
question when not explicitly permitted to do so using server-specific
local policy to override that default. are we still disagreeing?
>  
>>> So even the resolver can answer with NOTIMP. 
>> any RCODE other than 0 or 3 will cause spectacularly bad storms. i
>> prefer RCODE=0/ANCOUNT=0 to refuse "ANY".
> That would look confusing to me as it looks like an valid answer.

when someone is asking you something in DNS that you don't want to
answer, you have to answer them in a way that causes them to stop asking
you that question. NOTIMP and REFUSED do not have that property.

i'm fine with giving them an empty answer to a question they should not
be asking.
> NOTIMP looks clearer to me. What do you think this will cause given 
> that we want to get people of off it?

i think it will cause re-try storms, just like it always does.

see also this text:

http://www.circleid.com/posts/20120111_refusing_refused_for_sopa_pipa/
>
>> i heard several people enumerate the TCP initiators they could think of,
>> when arguing about whether to change the client's behaviour to
>> "keepopen". as i said there-- our ability to enumerate means precisely
>> nothing: if someone somewhere coded a reasonable expectation based on
>> RFC text and tested to work, then we have to act as if there are an
>> unknown, and treat as unknowable, but real and relevant set of users of
>> that encoding.
> I really could not parse or understand this. After reading it a couple of
> times I think that I say:
>      There is no reason to use RRSIG queries in a validator
> and you say:
>      It is not forbidden to use RRSIG queries in a validator
> both are true.

yes, sure, but...

> We can't stop people from doing unreasonable things.

...that is a complete nonsequitur, since you have not established that
QTYPE=RRSIG is unreasonable, whereas i think olafur and others have
amply demonstrated that QTYPE=ANY is unreasonable.

>
>> if you want to change how DNSSEC works, i'll listen. but there's no
>> reasonable interpretation of past or current specifications by which
>> QTYPE=RRSIG can be categorized a "meta-query". (unlike
>> QTYPE=ANY/IXFR/AXFR, or RD=0 when speaking to a recursive-only server.)
> I never said that RRSIG is a meta query. I said that implementing RRSIG
> is as hard as implementing ANY with regard to the aspect that you have
> to use/look for more than one query type, which is different from
> all other query types.

i see. so, are you proposing to change the way DNSSEC works, or not?
>
>> you could multiply all those numbers by six trillion, and they would
>> still not be relevant to the standard of care by which the DNS
>> specification must evolve.
> Yeah I noticed over the years that people were very concerned on even
> minor changes. Yet when I look at all the things that implementations
> of DNS servers did that were against the specs and others had to work
> around, maybe sometimes a disruptive change is good. One of the point
> of the numbers was to show that so far people have been reasonable 
> about RRSIG.

you're putting highly controversial and unsupported statements behind
the cover of the word "maybe." let me answer you with something less
controversial, more supported, and unmitigated:

> Complexity
>
> From this overview, it is possible to conclude that DNS is a poorly
> specified protocol, but that would be unfair and untrue. DNS was
> specified loosely, on purpose. This protocol design is a fine example
> of what M.A. Padlipsky meant by "descriptive rather than prescriptive"
> in his 1984 thriller, The Elements of Networking Style (Prentice
> Hall). Functional interoperability and ease of implementation were the
> goals of the DNS protocol specification, and from the relative ease
> with which DNS has grown from its petri dish into a world-devouring
> monster, it's clear to me that those goals were met. A stronger
> document set would have eliminated some of the "gotchas" that DNS
> implementers face, but the essential and intentional looseness of the
> specification has to be seen as a strength rather than a weakness.
>
> That having been said, a stronger document set written today would not
> be able to put all of the DNS genies back into their bottles. Too many
> implementations have guessed differently when presented with a loose
> specification, and interoperability today is a moving, organic target.
> When I periodically itch to rewrite the specification from scratch, I
> know there are too many things that must be said that also cannot be
> said. It's as though, in a discussion of the meaning of some bit
> pattern, a modern description of the protocol---written with full
> perspective on all that has been done in the DNS field---would have to
> say, "It could mean x but some implementations will think it means y
> so you must be cautious."
>
> If the objective meaning of a set of potential states and conditions
> and patterns has a complexity index that is a function, somehow, of
> the combinations and permutations of those states, conditions, and
> patterns, as well as the multiple interpretations and deliberate
> uncertainties, then DNS is a very complex system, even though its
> rules are simple and few, and even though a new DNS protocol agent can
> be constructed using only a few thousand lines of software code.

(from http://queue.acm.org/detail.cfm?id=1242499)

in summary, we've successfully rebuilt the DNS airplane in flight, not
just once but continuously, and we did it by never believing for an
instant that there was any possibility what you said: "maybe sometimes a
disruptive change is good". i'll stand behind the results, and the
approach taken to get those results.

-- 
Paul Vixie