Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications

Eugène Adell <> Tue, 12 April 2022 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 772D73A15AD for <>; Tue, 12 Apr 2022 07:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wWx2tKe4KvIE for <>; Tue, 12 Apr 2022 07:29:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15CFB3A12E8 for <>; Tue, 12 Apr 2022 07:29:21 -0700 (PDT)
Received: by with SMTP id f17so2494117ybj.10 for <>; Tue, 12 Apr 2022 07:29:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DjwJiauWIn0Kw3sTqyPy45UwcaWo922dcupOMxuFCBo=; b=lUuS6kYcMTjx0QcjKLBKiT3dklcJUIY3zifWMRbSqMMjtpBADImFsEj/HZq0poARbi 2faiSQfqzGRGwO6IyKohSkz+sI41jgJP1bxq6WjxPJC/EIsOw5s7mCbMrzTmbLnOUgwH IsoJiX47KIzPoWJjm6VJhwu83tZ7ChUOezaDohGqV1o2DRWY/YC+IB0i68i3/eY2Ghj/ F1r34KKY+ahyuRLf2wzi1q9tb2GAXT6zIna1XIkLxCi+9aKanWP/EQSWJu14cTlNC4hR 4LXGC5Rcg5SN7JuNcAQuO+b5Rlbmy4d6l9GRx3a2kc89l6PUsIuF6/Zg6pVJx48LhveA 1e2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DjwJiauWIn0Kw3sTqyPy45UwcaWo922dcupOMxuFCBo=; b=PtnIgGwW1lToLwxa/ToWH/Y6Hh+aGgpbh9SDq4WY2boR9N1mSUtKEjcv1qnkKHwg/1 229MnWxG+2EI6wEVembIWN+moKZu5cZ0gvas8Wz06kPmvGWkZNXaJFnLT25k3Jiy5XEY 1DELdaJbd/Ej79AjaymB5Td4YT6/s/8rdh4Y2eE2ZuiMcl3PM9LaeEqvAHfvNg8LmGFD VuKZGE59MQhW6Y0tFk0XI1fuwXEc53Ib/am2X9Y2ailMfBw30cFoh3QNm5CDR2MCkg7r EvJifDCocsZh5oZw5A2Iz6f5Bi+IATXhiXxx0m9JUwq1rgwVwXaqAzFp+eOzuu7Y9eID OklA==
X-Gm-Message-State: AOAM531yFQze0VswDcsGEKkE11EXuq5cbUW5WqCAjQ2Bmevxbjrif8gz s7IJ14Sem49rXJ2ui2a2Ttf5U2f3vR+nj+DYatRZVQgV
X-Google-Smtp-Source: ABdhPJx0y8+/LfVyKJQKA2Wb9/Qn1cIZCBBM6fUPUR76d9Xt0Qd9x1A8JxE1j+lnDh0UMdD4Gt8kC80KFC4GTDu43hs=
X-Received: by 2002:a25:1443:0:b0:63d:6c01:d26f with SMTP id 64-20020a251443000000b0063d6c01d26fmr28305052ybu.296.1649773759903; Tue, 12 Apr 2022 07:29:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Eugène Adell <>
Date: Tue, 12 Apr 2022 16:14:34 +0200
Message-ID: <>
To: Paul Wouters <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Apr 2022 14:29:26 -0000

Hi Paul,

in the implementation I suggested, the new DNS RR types are not used
for making people (administrator, decision-maker, CISO) communicating
together but as an information source that is simple enough to be
understood by everyone without the need of filtering and sorting data.
I commented that to explain why new types are necessary, although CRC
can be replaced with APL.

Why use DNS at all ? Likely many server software can be modified to
use the implementation suggested, while creating dependencies to
another protocol not already supported by the server looks worse. For
example, it's maybe not a good idea to update an FTP or LDAP server to
support HTTP only to download a text file containing these networks
allowed. And they would probably still need to start by a DNS request
to find that file.

If the Client DNS (CRC) is lying or not configured as asked by the
CISO, the client organization might expose data and it's an internal
threat to this organization. If the server DNS (CRS) is lying, the
client organization might complain as the contract (if any) is not
honored. If all is implemented/configured correctly and one client is
lying on its identity (wrong information sent during the
authentication for example), there is a mismatch between its real and
expected IP addresses, and no authorization at the end.

The use-case I'm thinking about is indeed for static entries handled
manually. In my past experience, I would say each company I worked for
would have benefited of some similar entries (5~10) without thinking
"big". The mechanism to authorize these records is somewhat
administrative for the CRC (the decision-maker asks the CISO who in
turns asks the DNS admin to add a record), and limited for the CRS (a
new application is brought online, with its own domain name, and an
associated CRS record). As it's intended for Business-to-business,
both parts still agree by another kind of contract, and I don't any
necessity to have something more for the provisioning.


Le mar. 12 avr. 2022 à 14:28, Paul Wouters <> a écrit :
> On Tue, 12 Apr 2022, Eugène Adell wrote:
> > Beyond the technical aspects, there are several different persons to
> > think about in our case : the DNS administrator obviously, the
> > decision maker buying (or not) a secured online service, and the CISO.
> Why should this information exchange happen via DNS?
> > It looks more simple to have dedicated RR types to let them
> > communicate together
> It seems a REST API using some .well-known HTTPS link seems a better
> fit ?
> > After your comments and correcting a typo, it gives
> >
> > Such domain name for sure doesn't exist and uses the underscore
> > character as separator. It has to be considered as storing data
> > establishing a kind of contract between the two organizations
> > involved.
> It should have a dot in between, eg
> Then, the underscore name should be uniquely identifying to split it
> from other DNS records. eg _crs or something. Have a look at other
> documents at
> > 5.
> > I give some explanation in the answer 1 but I will rephrase. The CRS
> > record can be used before subscribing to a service (typically any
> > storage/log system/SIEM) as an indicator that this service provides
> > the kind of authorization process described in the document.
> I still wonder if DNS is really the right fit for this.
> >   This document specifies the Client Roaming Control (CRC) DNS Resource
> >   Record allowing an organization to better control the access to
> >   third-party applications over Internet.  The applications
> >   implementing an authorization mechanism to honor the CRC, publish on
> >   their side the Client Roaming Support (CRS) Resource Record to inform
> >   of this support.
> There is a big overlap here with MUD, see
> It also seems the source of authorization depends on the DNS name, but
> how do you ensure a device would not be lying about their name? Would
> this only work on zones with static DNS entries? If so, how would that
> scale?
> What would be the mechanism to authorize the publishing of CRS/CRC
> records, and why can that provisioning protocol not also be used
> to query/signal this data?
> Paul