Re: [DNSOP] Definitions of foo-centric

Edward Lewis <edward.lewis@icann.org> Wed, 25 February 2015 15:38 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF11A8731 for <dnsop@ietfa.amsl.com>; Wed, 25 Feb 2015 07:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 bTvqU9V2my47 for <dnsop@ietfa.amsl.com>; Wed, 25 Feb 2015 07:38:41 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421EE1A1B0E for <dnsop@ietf.org>; Wed, 25 Feb 2015 07:38:41 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Wed, 25 Feb 2015 07:38:39 -0800
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.0847.030; Wed, 25 Feb 2015 07:38:39 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] Definitions of foo-centric
Thread-Index: AQHQUNlPtglP9kT6PEG6UKGl1dxh3Z0Bm3CAgAABcwCAAE9GAP//xqqA
Date: Wed, 25 Feb 2015 15:38:39 +0000
Message-ID: <D1135363.9428%edward.lewis@icann.org>
References: <20150225085816.GB24102@nic.fr> <21E596E7-E156-446F-9B80-2AD9B7F24A0A@nominet.org.uk> <20150225092003.GA30956@nic.fr> <20150225.150348.396032001.he@uninett.no>
In-Reply-To: <20150225.150348.396032001.he@uninett.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3507705515_13567508"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/6JHfMEJhg4Q9oJD2f26tCvMpVuI>
Subject: Re: [DNSOP] Definitions of foo-centric
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Wed, 25 Feb 2015 15:38:49 -0000

On 2/25/15, 9:03, "Havard Eidnes" <he@uninett.no> wrote:

>Hmm.
>
>Firstly, isn't this "child-centric resolver" / "parent-centric
>resolver" simply an euphemism papering over the more distinct
>"correctly" and "wrongly" implemented resolver?

That’s my thought exactly.  (But that doesn’t mean the terms needn’t be
given definitions.)

>A correctly
>implemented resolver implements the DNS authority model, and to do
>that requires that the resolver replaces non-authoritative cached data
>with more authoritative data whenever it is obtained.

To put a sharper point on this, this is documented as “trustworthiness” in
“Clarifications to the DNS Specification” [RFC 2181] inside section 5.4.1
on “Ranking Data."

I’ve seen a case of a resolver that favored the parent NS set over a child
NS set (and glue), which led to a cache poisoning event.  A delegation
that was transferred forgot to remove the glue records in the TLD, an
apparently disgruntled employee aware of this left the company, registered
a new domain that made use of the glue record.  (I’m omitting details to
make this quick.)  The net result is that the caches following this model
quickly favored the stale glue over the fresh authoritative answer,
victimizing the registrant.

Nevertheless, giving the practice a name will make it easier to explain to
someone why it’s a bad idea.

>  The perhaps
>most prominent example of non-authoritative data is the copy of the NS
>RRset from the child zone which exists in the parent zone.

And/or the glue.

>>Phantom domain: ...
>
>Again, I'd simply call a resolver allowing this situation to persist
>to be "wrong/buggy".

In operations, you have to deal with the bad a lot - in fact, by the very
nature of the bad being bad, you deal more with the bad than the good.
(The good is hidden under automation.)  Giving names to the bad is very
helpful for that reason.  (Root cause voice call recordings, staff
turnover, these are places where common terminology is helpful regardless
whether the term describes something good or something bad.)