Re: [dane] Behavior in the face of no answer?

Martin Rex <mrex@sap.com> Fri, 04 May 2012 17:24 UTC

Return-Path: <mrex@sap.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6AA21F8638 for <dane@ietfa.amsl.com>; Fri, 4 May 2012 10:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.126
X-Spam-Level:
X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9bFijp7yUwN for <dane@ietfa.amsl.com>; Fri, 4 May 2012 10:24:44 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D0B5B21F8637 for <dane@ietf.org>; Fri, 4 May 2012 10:24:41 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q44HObdB017838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 May 2012 19:24:37 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201205041724.q44HOars012930@fs4113.wdf.sap.corp>
To: ajs@anvilwalrusden.com (Andrew Sullivan)
Date: Fri, 4 May 2012 19:24:36 +0200 (MEST)
In-Reply-To: <20120504112015.GA4929@mail.yitter.info> from "Andrew Sullivan" at May 4, 12 07:20:42 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: dane@ietf.org
Subject: Re: [dane] Behavior in the face of no answer?
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 May 2012 17:24:45 -0000

Andrew Sullivan wrote:
> 
> Martin Rex wrote:
> >
> > Andrew Sullivan wrote:
> > > 
> > > Note that there remain _plenty_ of DNS servers deployed in the wild
> > > which, if you ask them for an RRTYPE they don't know about, spit up
> > > with NOTIMP, SERVFAIL, and all manner of other crappy nonsense.
> > 
> > You seem to be unaware that returning SERVFAIL and more so NOTIMP
> > to requests for unknown RRTYPES is *PERFECTLY* conformant with
> > rfc1034/rfc1035.  So if anything is _broken_, its clients who can
> > not cope with such responses (as can be seen with the IPv6 dualstack
> > in Windows2003).
> 
> I'm not unaware of this (although I think there is rather less
> consensus about the correctness of those RCODE responses than you seem
> to be suggesting).  I just think it's crappy.

Not at all crappy, it's perfectly valid.

If you look at this:

http://tools.ietf.org/html/std13

that is an IETF "Full Standard" (and the above does not even mention
any updates at all).


>
> RFC 3597 was published in 2003.

So what?  That seems to be a totally irrelevant RFC.  

The document itself is only proposed, so it pales in comparison
to STD, but what's the real issue, there is not the slightest sign
that it has anything to do with STD13!  There is neither meta-data
nor any mentioning in the Abstract/Intro that this document is
supposed to apply to STD13 (rather than being just another optional
and irrelevant extension).


>
> There is no excuse any more for a server of any sort to be
> incapable of handling unknown RRTYPEs.

Just the opposite.  According to the IETF process, STD13 clearly
suggests that NOTIMP is the most reasonable response to a request
for an unknown RRTYPE.


>
> I get the arguments about
> provisioning systems, and I think they're real problems.  But by now,
> if your _server_ doesn't handle unknown RRTYPEs it is plainly garbage,
> and ought to be off the Net.

I don't know what documents are looking at, but STD13 is pretty clear,
your _clients_ are the ones that are broken.


> 
> The fundamental problem, of course, is that people who are told to go
> develop a DNS server in a weekend read RFC 1034 and RFC 1035 --

= STD13.  That is what standards at maturity level "full standard"
were made for.


>
> usually selectively, it appears to me -- and nothing else.  I wish I
> had a good idea about what to do about this.  (That's all I'll say
> about it here, though, because it's plainly off-topic.)


Follow the IETF process.

So first of all, the same housekeeping that was done with

   821 -> 2821 -> 5321
   822 -> 2822 -> 5322

will have to be done for DNS, i.e. all real(!!) updates&changes that
are relevant to the base DNS standard will have to be merged into
a new set of 2-3 documents and "completely replace" STD13.

After that is accomplished, it will take 10-15 years for the
installed base of STD13 to die of age or get updated.


-Martin