Re: [DNSOP] DNSOP Presentation "The Camel"

Mark Andrews <marka@isc.org> Tue, 20 March 2018 22:44 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B473812D775 for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 15:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.89
X-Spam-Level:
X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K515dOqgOhIi for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 15:44:22 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EB712D7F1 for <dnsop@ietf.org>; Tue, 20 Mar 2018 15:44:11 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BC3A93AB046 for <dnsop@ietf.org>; Tue, 20 Mar 2018 22:44:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9E8EE160086 for <dnsop@ietf.org>; Tue, 20 Mar 2018 22:44:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 87EBF16006C for <dnsop@ietf.org>; Tue, 20 Mar 2018 22:44:10 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LgX4Byn8HIo8 for <dnsop@ietf.org>; Tue, 20 Mar 2018 22:44:10 +0000 (UTC)
Received: from [172.30.42.90] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9DC10160053 for <dnsop@ietf.org>; Tue, 20 Mar 2018 22:44:09 +0000 (UTC)
From: Mark Andrews <marka@isc.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 21 Mar 2018 09:44:07 +1100
In-Reply-To: <20180320151201.GA22384@laperouse.bortzmeyer.org>
Cc: dnsop <dnsop@ietf.org>
References: <CADyWQ+GK9kkkPAHUy1ZNV1NhK_hsQcedmi17UJqb6ZKtwHA3FQ@mail.gmail.com> <20180320151201.GA22384@laperouse.bortzmeyer.org>
Message-Id: <F172531A-0FB4-4AD4-8BCC-54766A0ACCAD@isc.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vHAcOqJ6kRHRWUmpEuQBma5rmNA>
Subject: Re: [DNSOP] DNSOP Presentation "The Camel"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2018 22:44:25 -0000

QNAME minimisation failures happen for 2 reasons.

1. Bad implementations of DNS that don’t return ENTs in a zone.

2. Failure to add delegating NS records to the parent zone resulting
   in no ENT being emitted when both the child and parent server are
   served by the same server.

If we had kept going with bit-string labels querying for the longest
sequence of labels on the RHS without a bit-string label would have
been been the way to get to the servers that supported bit-string labels.

DNS COOKIES has problems because there are bad implementations of EDNS
out there.  Whatever we did when introducing them ran up against broken
implementations (includes bad firewalls) (DNS COOKIES alone or EDNS(1) and
DNS COOKIES).

1. Servers that DO NOT respond to queries with EDNS options present.
2. Servers that return BADVERS, NOTIMP to EDNS queries (STD13 says return
   FORMERR to unknown queries).  RFC 6891 turned this to NOERROR on unknown
   EDNS option.
3. Servers that echo back the option, who is insane enough to send bits that
   you don’t understand them meaning of! (this one is not fatal for DNS COOKIE).
4. Servers that don’t return BADVERS to EDNS(1) + EDNS Options but return FORMERR.
5. Servers that don’t answer EDNS(1) + EDNS Options.
6. Load balance front ends that punted to poorly configured backends when they
   saw a EDNS option.  This leads to NXDOMAIN and other bad data being returned.
7. Other random rcodes.

All of this was testable for by developers when they introduce EDNS to
their servers. EDNS has 3 extension mechanism. That is not a lot of test
case to write and think about does the response you see make sense?

EDNS(1) query                                   (behaviour fully described in RFC 2671)
EDNS unknown option query                       (behaviour fully described in RFC 6891)
EDNS unknown flag query                         (behaviour fully described in RFC 2671)
EDNS(1) query + EDNS unknown option             (behaviour fully described in RFC 6891)
EDNS(1) query + EDNS unknown flag               (behaviour fully described in RFC 2671)
EDNS unknown option + EDNS unknown flag         (behaviour fully described in RFC 6891)
EDNS(1) query + EDNS option + EDNS unknown flag (behaviour fully described in RFC 6891)

One shouldn’t have to say to DNS developers “test you servers against
possible extension methods before you ship it!"  That should be part
and parcel of adding EDNS support.

I can find servers that fail one or more of every one of these tests.

> On 21 Mar 2018, at 2:12 am, Stephane Bortzmeyer <bortzmeyer@nic.fr>; wrote:
> 
> On Tue, Mar 20, 2018 at 07:29:50AM +0000,
> tjw ietf <tjw.ietf@gmail.com>; wrote 
> a message of 94 lines which said:
> 
>> At the end of Tuesday's session we're having Bert Hubert from Power DNS
>> give a talk on what he views "The Camel".
> 
> Unlike the popular saying
> <https://en.wikipedia.org/wiki/Design_by_committee#Aphorisms>;, camels
> are extraordinary animals, well adapted to their harsh environment
> <https://en.wikipedia.org/wiki/Camel#Ecological_and_behavioral_adaptations>
> and usable for many things, even war
> <https://en.wikipedia.org/wiki/Camel_cavalry>;. If the DNS is a camel,
> this is great!
> 
>> "In past years, DNS has been enhanced with DNSSEC, QName
>> Minimization, [...]
> 
> I dispute the idea that QNAME minimization is an addition. It is not a
> change in the protocol, and it was even possible from the beginning
> (Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate
> QNAME maximimization, it is just an accidental evolution).
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org