IETF Logo Mail Archive

Re: [dbound] BoF request for IETF 115

"Vixie, Paul" <upavixie@amazon.com> Thu, 22 December 2022 05:38 UTC

Return-Path: <prvs=348669512=upavixie@amazon.com>
X-Original-To: dbound@ietfa.amsl.com
Delivered-To: dbound@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D54AC14CF01 for <dbound@ietfa.amsl.com>; Wed, 21 Dec 2022 21:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.901
X-Spam-Level:
X-Spam-Status: No, score=-11.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQCxGJHp7cOD for <dbound@ietfa.amsl.com>; Wed, 21 Dec 2022 21:38:46 -0800 (PST)
Received: from smtp-fw-80007.amazon.com (smtp-fw-80007.amazon.com [99.78.197.218]) (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 0FE76C14F721 for <dbound@ietf.org>; Wed, 21 Dec 2022 21:38:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1671687527; x=1703223527; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=E5nql6iPpIircrq8GsVX0L+b/FTao5ZMxj67hgw8Yxw=; b=YSWwP1RX2+fhcLMt/W1ALSAMrl6wv6JJZG/zr3cEaP6usnrFOSihU0r+ wgpd5iVOxPZ+Esf1+V+cfEMj9MY9/CVGcnFpY4hIpuhuekOdIEWyOhb62 HYgA8wOtX1iajYudqSTqCbZ/hoGjL3P2CVCjlItOL2VIr1NLd7+Z8Y8T9 k=;
X-IronPort-AV: E=Sophos;i="5.96,264,1665446400"; d="scan'208";a="164204793"
Thread-Topic: [dbound] BoF request for IETF 115
Received: from pdx4-co-svc-p1-lb2-vlan3.amazon.com (HELO email-inbound-relay-pdx-2c-m6i4x-fa5fe5fb.us-west-2.amazon.com) ([10.25.36.214]) by smtp-border-fw-80007.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2022 05:38:44 +0000
Received: from EX13MTAUWB001.ant.amazon.com (pdx1-ws-svc-p6-lb9-vlan3.pdx.amazon.com [10.236.137.198]) by email-inbound-relay-pdx-2c-m6i4x-fa5fe5fb.us-west-2.amazon.com (Postfix) with ESMTPS id 240394212D; Thu, 22 Dec 2022 05:38:43 +0000 (UTC)
Received: from EX19D036UWB002.ant.amazon.com (10.13.139.139) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 22 Dec 2022 05:38:42 +0000
Received: from EX19D036UWB002.ant.amazon.com (10.13.139.139) by EX19D036UWB002.ant.amazon.com (10.13.139.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.20; Thu, 22 Dec 2022 05:38:42 +0000
Received: from EX19D036UWB002.ant.amazon.com ([fe80::23a6:1fe3:c104:21b6]) by EX19D036UWB002.ant.amazon.com ([fe80::23a6:1fe3:c104:21b6%4]) with mapi id 15.02.1118.020; Thu, 22 Dec 2022 05:38:42 +0000
From: "Vixie, Paul" <upavixie@amazon.com>
To: John R Levine <johnl@taugh.com>
CC: "dbound@ietf.org" <dbound@ietf.org>
Thread-Index: AQHZFaMWdfLQrndV/kK/FA7vXaeIqa55OvYA//+i84A=
Date: Thu, 22 Dec 2022 05:38:42 +0000
Message-ID: <0E589D51-AB3C-4E8A-8F57-33FFD579B31E@amazon.com>
References: <CAL0qLwaePPropS=uijZ5iu5xJN=4PabY-F_hCG-MQ68+dwX3Bw@mail.gmail.com> <20221221185656.AD56856D7051@ary.qy> <7B0AA07F-29DD-4834-A32C-C3E48E181CBA@amazon.com> <c52ade51-b30d-ff5c-2f6b-800227452978@taugh.com>
In-Reply-To: <c52ade51-b30d-ff5c-2f6b-800227452978@taugh.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.106.100.29]
Content-Type: text/plain; charset="utf-8"
Content-ID: <01E5C0D38857C84EA3DF1D6559F4C4D4@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dbound/u5iED5HBLejj4srogXRv88fDmb8>
Subject: Re: [dbound] BoF request for IETF 115
X-BeenThere: dbound@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: DNS tree bounds <dbound.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dbound>, <mailto:dbound-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dbound/>
List-Post: <mailto:dbound@ietf.org>
List-Help: <mailto:dbound-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dbound>, <mailto:dbound-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Dec 2022 05:38:50 -0000

See inline.

-- 
Paul Vixie
VP & Distinguished Engineer

-----Original Message-----
From: John R Levine <johnl@taugh.com>
Date: Wednesday, December 21, 2022 at 19:12

    ... Take another look at my draft.  If we expect each TLD to publish its own
    dbound records, it's not practical to extract them mechanically from the
    zone.

I will take another look. I think that the aggregator (someone like the PSL team is today) who wants complete coverage ("to be relevant and successful") will have to invite people to enter things into some kind of corpus (via web site, API, whatever). Today ("the PSL") they supply a record. In a post-DBound world I expect they will supply a domain name. These domain names will drive a mechanical extraction process whereby the actual data is found (or not) in the DNS itself. Only aggregators (like the PSL team is now) and their audiences will care about this.

    ... I suppose I coould tweak it and put in some links to make the lower
    level records easier to find, but that's one of those things that doesn't
    exist yet that I referred to.

    I think Casey's design has the same problem.

I think that would be a mistake. Putting the data into the DNS itself makes it possible to look it up in real time (similar to how ASN information is looked up in real time by https://github.com/dnsdb/dnsdbq). Aggregation would be a valuable second use case but the aggregator will have its own way to know (see above) what periodic real-time lookups to make.

I think there is no way to reach consensus on a high quality way to directly support aggregation. So we just have to improve that aggregation over how things work today in order to drastically reduce the work load for teams like PSL and drastically improve the capabilities for non-aggregation-based work flows.

v2.23.0 | Report a Bug | By Email