IETF Logo Mail Archive

[DNSOP] DNS cookies and multi-vendor anycast incompatibility

Petr Špaček <petr.spacek@nic.cz> Wed, 20 June 2018 08:40 UTC

Return-Path: <petr.spacek@nic.cz>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9E0130E55 for <dnsop@ietfa.amsl.com>; Wed, 20 Jun 2018 01:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 1H_79_BQ4d0A for <dnsop@ietfa.amsl.com>; Wed, 20 Jun 2018 01:40:30 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 06256124BE5 for <dnsop@ietf.org>; Wed, 20 Jun 2018 01:40:29 -0700 (PDT)
Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id 3BE1360527; Wed, 20 Jun 2018 10:40:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1529484028; bh=a61JxDscSjoUCjtNLtsqDSk9YOMbw1/RYeo2SlUQ4N0=; h=From:To:Date; b=XaxaHn1Wu/LPLqBiXhDlSRSUKtkPMuolNj8bCRwdk87i3B2oL+nPlhcflqPZtI/Mv H9bJ/dcu7QxYYWqRpiPIzMvOLHH2XTPJ+ebvhAXx9WmEAAmK9t7fpVDArDTI4c2BH9 CHcPFSXHj8cc2GJ38xfQbEK/qjR2afP1i5+CEdrM=
From: Petr Špaček <petr.spacek@nic.cz>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Cc: Daniel Salzman <daniel.salzman@nic.cz>
Organization: CZ.NIC
Message-ID: <c70f058c-8e82-f905-e352-f3e2fd0d4cfc@nic.cz>
Date: Wed, 20 Jun 2018 10:40:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gh0e9tdl_BKMxmcoAcjT-0lZQpA>
Subject: [DNSOP] DNS cookies and multi-vendor anycast incompatibility
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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, 20 Jun 2018 08:40:32 -0000

Hello dnsop,

it seems that current specification of DNS cookies in RFC 7873 is not 
detailed enough to allow deployment of DNS cookies in multi-vendor 
anycast setup, i.e. a setup where one IP address is backed by multiple 
DNS servers.

The problem is lack of standardized algorithm to generate server cookie 
from a shared secret. In practice, even if users manually configure the 
same shared secret, Knot DNS and BIND will use diffrent algorithm to 
generate server cookie and as consequence these two cannot reliably back 
the same IP address and have DNS cookies enabled.

One of root server operators told me that they are not going to enable 
DNS cookies until it can work with multi-vendor anycast, and I think 
this is very reasonable position.

So, vendors, would you be willing to standardize on small number of 
server cookie algorithms to enable multi-vendor deployments?

-- 
Petr Špaček  @  CZ.NIC

v2.23.0 | Report a Bug | By Email