Re: [DNSOP] [Ext] Re: tdns, 'hello-dns' progress, feedback requested

Edward Lewis <edward.lewis@icann.org> Fri, 13 April 2018 20:19 UTC

Return-Path: <edward.lewis@icann.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 10ADA1289B0 for <dnsop@ietfa.amsl.com>; Fri, 13 Apr 2018 13:19:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 TQxEAZghNmCu for <dnsop@ietfa.amsl.com>; Fri, 13 Apr 2018 13:19:43 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA74127978 for <dnsop@ietf.org>; Fri, 13 Apr 2018 13:19:43 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 13 Apr 2018 13:19:41 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Fri, 13 Apr 2018 13:19:41 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: Matthew Pounsett <matt@conundrum.com>, bert hubert <bert.hubert@powerdns.com>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] Re: [DNSOP] tdns, 'hello-dns' progress, feedback requested
Thread-Index: AQHT0zgIDK+p1YMzN0KpO0uEzrMwk6P/QmkAgABAcwD//9J/AA==
Date: Fri, 13 Apr 2018 20:19:40 +0000
Message-ID: <8A0830D6-A9AE-4D3D-B4C9-3C2F7A4103E7@icann.org>
References: <20180413144707.GA4767@server.ds9a.nl> <623F11C7-6E4D-40F5-8AD1-8F7E92C8C7F9@vpnc.org> <20180413151152.GB4767@server.ds9a.nl> <CAAiTEH_wF7NMpMv0MQ4-VbCZUSYWA7QsivgSoYM2p128EsL4zQ@mail.gmail.com>
In-Reply-To: <CAAiTEH_wF7NMpMv0MQ4-VbCZUSYWA7QsivgSoYM2p128EsL4zQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5111FFFCC42DD645A94439647CC797DA@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qAgAaPHoHQbCcVuxTb8WCiDqqoM>
Subject: Re: [DNSOP] [Ext] Re: tdns, 'hello-dns' progress, feedback requested
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: Fri, 13 Apr 2018 20:19:45 -0000

On 4/13/18, 15:02, "DNSOP on behalf of Matthew Pounsett" <mailto:dnsop-bounces@ietf.org on behalf of mailto:matt@conundrum.com> wrote:

>On 13 April 2018 at 11:11, bert hubert <mailto:bert.hubert@powerdns.com> wrote:

>>RFC 1034, 4.3.2, step 3, a. It says to go back to step 1, which means that
in step 2 we look up the best zone again for the target of the CNAME. I have
not looked if newer RFCs deprecate this or not. So with 'chase' I mean,
consult other zones it is authoritative for. There might be millions of
these btw, operated by other people.

>Wouldn't there be a security concern with doing that?

Certainly.

And you just woke up a hole I've seen but not realized.

A name server may be properly authoritative (legit?) for a zone - meaning that somehow, when consulting the (grand)parent of the zone on another server, you can manage to get to the zone.  (The wording here is hairy as I'm accounting for cases where the NS sets above the cut and below the cut aren't the same, having some overlap.  Yes, that's broken, but it works.)

Name servers may also be configured to host zones they "ought not" (ill-legit) - such as a zone of an exited customer of a DNS hosting service.  I know this could happen in multi-tenant hosting providers who don't check whether their customers are registered "owners" of the zones the customer configures.  Or forget to clean up after departed customers.

If a name server CNAME chases from a "legit" zone to an "ill-legit zone" things could get interesting, especially when debugging.

I have thought, for a very long time, "chasing" of any DNS "rewrite rule" is wrong - CNAME or DNAME.  Leave the query gymnastics to the DNS iterator, the trust policy ought to be homed at the searcher's end.  But that is just opinion...

Oh, I meant to say - the above opinion I had when I worked for a hoster.  Since the hoster charged by query volume, if I had made that public I'd be accused of trying to raise revenue artificially.  But as a protocol analyst, I think that a few more queries is worth the simplicity...but you can argue "round trips" and all latency problems...but then I'd argue "that's what caching is for...