Re: [DNSOP] New draft for ALIAS/ANAME type

Matthew Pounsett <> Tue, 04 April 2017 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAF921296D2 for <>; Tue, 4 Apr 2017 09:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 4lIlmCY33WbX for <>; Tue, 4 Apr 2017 09:32:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC02E12422F for <>; Tue, 4 Apr 2017 09:32:07 -0700 (PDT)
Received: by with SMTP id r69so181924462vke.2 for <>; Tue, 04 Apr 2017 09:32:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mX9gTBmsTaa00Jzmwp3OT8LKdsnsRHBujy/S/CgjWWc=; b=G4l6pE25OicwMADHn4Vbnn0hqGEzhLKnNSmp1ZBLob0DG9Rpa9ThnSXj/DkBGcwvDR WsJlbdwzQ/dROgpidzaC80OP9DJsMsNn6DEXTUqq/zHa0WIVrl/XyiCftq6Wa/yjJwB8 jh++d2uq9UGa9+nSiDxq9GMhg8jyHi7G2y2k7K+mk41d6kCrWJNQhJrOi6Sx62BVg4QQ vFqyneTaFJmFJjM9xKm23QS6s4pJ3aic9hPJAJyrnb8D181R3W9MTAFDXEr3eXJhdz21 IkLtPwgTx22IGx2qt9lm9zCR8cXd0ivGqbPnD4Cd+1z4ASd3U4YBCgnZzVnd4KL3YwhU J9hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mX9gTBmsTaa00Jzmwp3OT8LKdsnsRHBujy/S/CgjWWc=; b=ZMHJbhhVAhaIqPQPQVdvokQPnchiD/UuLrPkVnYwH4Q25iEl8VNy9tKY52xOFaRK/Q GU3rjdfPEhPey2xUlXcXiPKgpCimwSwe7ovy25AB8wuhAqONjZWLptsNj5CCS9ffh0bq WG7KsO46NsFOPT7vQz6KRHIMxtSItBOXtupc7LxcAaJm174+UrLUEcApHrYIiKD9Ht5y rUFCmSfNoQ9pCgBY3ACn9L78OBgGRaWrZpYlKhoQ/vfuoaNdp00wwsGgzEZGSI8epiud dpVykWWyzntl5A6BGsB3WMs2ERienrwUd3gAzYcBoXrxCFoZRzuuI5gzt/W9aG0c2HKM Q4Bw==
X-Gm-Message-State: AFeK/H3DOtfDa2tiBx/NHLVFrWTukMAsxPKaLnzSis0VIulROmuV+al6q6wFC6xt0WpzlsAd5QRSpQ3isDmpjw==
X-Received: by with SMTP id 97mr10194361uas.158.1491323526362; Tue, 04 Apr 2017 09:32:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 4 Apr 2017 09:32:05 -0700 (PDT)
In-Reply-To: <>
References: <20170330230806.6273.qmail@ary.lan> <> <>
From: Matthew Pounsett <>
Date: Tue, 04 Apr 2017 12:32:05 -0400
Message-ID: <>
To: Tony Finch <>
Cc: Peter van Dijk <>, dnsop <>
Content-Type: multipart/alternative; boundary="001a113d1444092c8c054c59d12b"
Archived-At: <>
Subject: Re: [DNSOP] New draft for ALIAS/ANAME type
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Apr 2017 16:32:22 -0000

On 3 April 2017 at 07:55, Tony Finch <> wrote:

> If you expand ALIAS on the master server like this, I would expect that
> most of the time the target addresses won't change very frequently, so the
> IXFR rate should be much less than the ALIAS polling frequency.

I believe that's a faulty assumption.   Here's some data:

One of our registrars has ~3.6 million zones hosted on its name servers.
We have historically allowed end users to put CNAMEs wherever they want in
the UI, but have a CNAME "emulator" in the publishing path replaces the
illegal ones before they're inserted in a zone.

During the month of February, the CNAME emulator initiated 872k changes to
28k zones, with an average of 31 changes per zone.  The minimum/maximum
changes per zone were 1 and 231 respectively.

A change is updating one or more replaced CNAME records in a single action,
so this doesn't count individual CNAMEs updated.  It's also possible actual
changes occurred on authoritative servers more often, since we avoid DoSing
upsteam authoritatives.

Here's the distribution of the  number of zones per number of changes.
I've used a LOG scale, since there's a spike of 10k zones with 42 changes,
which makes a linear graph unreadable.