[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/