[DNSOP] Domain Connect DNS Provider Extensions
Sami Kerola <kerolasa@cloudflare.com> Tue, 10 June 2025 12:28 UTC
Return-Path: <kerolasa@cloudflare.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4E7763324C3A for <dnsop@mail2.ietf.org>; Tue, 10 Jun 2025 05:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudflare.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj5HK5INsQIS for <dnsop@mail2.ietf.org>; Tue, 10 Jun 2025 05:28:30 -0700 (PDT)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A77B63324C26 for <dnsop@ietf.org>; Tue, 10 Jun 2025 05:28:30 -0700 (PDT)
Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-6f8a87f0c0fso58932386d6.0 for <dnsop@ietf.org>; Tue, 10 Jun 2025 05:28:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1749558510; x=1750163310; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=cbaAaO0tpwuC6sNcOcwEokE8E7A7v2jZjtAytkkl170=; b=Ru3wPWscFa9knHfmQSE5iyv9Ph97oBvmMuHEoWoUPy/AfUd3qrcXoBKKE3h/RplvmM i1vUOyGqtyjVpP/9ZmXUnrMwAtU0cu3Y+imlh89+9E3Zziezon8V08nF+O+HISWXeIDW pbOcDjfCC+pHxtXvqmzNenghvxcWUc9L9p8zO9n5nBChM52cpwbvR0oQLM3BZVG+/qtO Nua72STkiNrXUKqq1ccYM9hqnoLxJqVPt47Xl1rJiTQ78BCkHgh3WYcVwDq9YHNTQn7p zhRmscJKpZqaL52imksoMTVsQSMR+sCYo1b4GPqHXqCaknBm16GfWG80OLDX4LyG3MvW DkaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749558510; x=1750163310; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=cbaAaO0tpwuC6sNcOcwEokE8E7A7v2jZjtAytkkl170=; b=E9UmovGAaci2nh712DsmudPxokjG5ERGeDiXxJ62+opkui4X+FlOrN24ml4SwN9TY+ fAhPmKHPtyu4kRiEhFTNjS4xM/0r2NtAuuJKKcFzW4UivMQ+f68B8WugrbQiEw/NYOgN QiQlmp+jfx0Ag0IQicEoQWnX+TQLD8V/yvpLNlu9vEzDjfWVfRM+bwiXHlHfaP9g0I1y TvHUt/HabvLwxKqhExn4t2ug1PppQlvyHaLqlUIylYNPXqYQa9cWpNxCsLnyXR+UuYP3 H5Ux+FFycpU0uMRL0bLdaLFnxnc/bCPrR4GMm2EXirQwgGBqFEDY5tqbpNYS7zWo9kWB +DPg==
X-Gm-Message-State: AOJu0YweD9CNF9/aDKelCZ0KVRh7P5QEXjFXlxAjPpzSO239ZVesh1pF u19qpO+vmBURcu4OGcU3LaskfSV2G1rWbqzcdHYTE2tHwMqPGybE3Pj8BUpThX+t/GptaXksMpA xK7HqtMMzqHXmdNchSA5QEtq8QhuYJAwUSdieNkBvszTA7F9CoP7R+Jk=
X-Gm-Gg: ASbGncsm4+5u8qAH02tjx9x/4kWOOnchTJsQNfgRPCu9gZYbX+gLs8uyHom3/OcEZd+ m/sTZpGTeM42egHulTqF/W+vWOpvO/cEGY8JdbXR9MTff0J0jULthV1e+TQpriV/7YeIFmsSG6l VdwleuXUeJwryu3EbXzjItE8EJP0ZtNX/XrV0tWPwIpQoVAJdroMB4zaV5EG+cqQ==
X-Google-Smtp-Source: AGHT+IEwCAevhDFAhbo1wZrKaXcOpv1SJ0LVxeu2b1Z3TrMlwXdTupYrMCMawoUIIql8tjYLNihx8TSlShkrFc9kpbQ=
X-Received: by 2002:ad4:5c41:0:b0:6e8:fbb7:6764 with SMTP id 6a1803df08f44-6fb24cd4db3mr38594576d6.45.1749558509924; Tue, 10 Jun 2025 05:28:29 -0700 (PDT)
MIME-Version: 1.0
From: Sami Kerola <kerolasa@cloudflare.com>
Date: Tue, 10 Jun 2025 13:28:18 +0100
X-Gm-Features: AX0GCFt8eimg2rVVuTnsZW_4j7H6plRT9m7M2sPtWRSQjkvamJk1djeZPD4D2Xk
Message-ID: <CAEnV9zpxpUyM+h7VjD4wip+Jz6RBtDyHc_2h38KWVuHV-twA2A@mail.gmail.com>
To: Domain Connect <dconn@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007f94a6063736d55f"
Message-ID-Hash: SI2ZKNEROT7SDM4VVOGZXVFEPGEYMCMI
X-Message-ID-Hash: SI2ZKNEROT7SDM4VVOGZXVFEPGEYMCMI
X-MailFrom: kerolasa@cloudflare.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: DNS Operations <dnsop@ietf.org>, Applications and Realtime <art-ads@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Domain Connect DNS Provider Extensions
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NOI3OZcEsq25AUBiC7XS1_0rMK8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>
Hello all, This email is in context of draft-kowalik-domainconnect proposal https://datatracker.ietf.org/doc/draft-kowalik-domainconnect/ that I hope people receiving this email have heard or might even be somewhat familiar. Proposal has a service discovery mechanism that uses DNS TXT record to locate DNS Provider. Assuming the provider is found Service Provider can proceed checking if DNS Provider has a specific Service Provider template available, and if so apply the changes. That is 99% good and great. My and Cloudflare's problem with the update flow is non-standard DNS extensions. It would be great if the DNS Provider response could have further instructions to Service Providers. At the moment the DNS Provider responses look like this: { "providerId": "cloudflare.com", "providerName": "cloudflare", "providerDisplayName": "Cloudflare", "urlSyncUX": "https://dash.cloudflare.com/domainconnect", "urlAPI": "https://api.cloudflare.com/client/v4/dns/domainconnect" } With extensions response could look something like this: { "providerId": "cloudflare.com", "providerName": "cloudflare", "providerDisplayName": "Cloudflare", "urlSyncUX": "https://dash.cloudflare.com/domainconnect", "urlAPI": "https://api.cloudflare.com/client/v4/dns/domainconnect", "Extensions": { "settings": [ { "flow": "synchronous", "syncPubKeyDomain": "required", "warnPhishing": "notsupported" } ], "records": [ { "type": "A", "proxied": "bool" }, { "type": "AAAA", "proxied": "bool" }, { "type": "CNAME", "proxied": "bool", "flattened": "bool" } ] } } Extensions have relation to Domain Connect templates. The key-values in settings segment attempt to clarify how things need to be applied to the DNS Provider, and what one can expect as requirement and/or support. In the records list type key is required and it tells what additional apply?[properties] key-values the DNS Provider expects. All the records in an apply set will use the same value for each key, for example the proxied. In case Service Provider wants to mix proxied and unproxied records in an update to Cloudflare then Service Provider must apply template part-by-part. When record specific instructions are not defined as an apply property then DNS Provider can default to whatever makes most sense. These instructions are OPTIONAL. To summarize. Extensions could be quite useful for DNS Provider specific quirks, that are unpredictable in nature. All and each provider can have various extra settings without relation to each other. What do you think, does that make sense? Could the next draft version include DNS Provider extensions? -- Sami Kerola https://kerolasa.iki.fi/
- [DNSOP] Domain Connect DNS Provider Extensions Sami Kerola