Re: [dane] domain hijacking

Wei Chuang <> Thu, 13 April 2017 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C12B124D68 for <>; Thu, 13 Apr 2017 07:06:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 5JO0QpGZPDwm for <>; Thu, 13 Apr 2017 07:06:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8D8D126FDC for <>; Thu, 13 Apr 2017 07:06:51 -0700 (PDT)
Received: by with SMTP id z204so28516402vkd.1 for <>; Thu, 13 Apr 2017 07:06:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXQO3mJ2iHtl5+ppkc+EnpSnK08ckUbrE46VWfw45zU=; b=VMEQmhKhC/KfQDQavV7f7mm2hBEYGtssFLJR64XwX9Rlbv7cfCUHThEQbPTxkTNAXL m5DcvRiF+Y23sIkaQY0S4FJoeifoyxoWsaJ8voOFcZf5bEX5il4+TO9YsKK/PbfqmaZP aqTNF2aqhmRsPXhdfU0bO+Ok7XE63q3SoYGTi/96lDXJc2+Ofteg0KdXqHe1j6SLgEe8 jTIEZ+LbdxyV1ek0MbK6MOHjxP2i8yJfBm31pHX4cP9Mi2TcSwMpQvJQ8c8Q3KBU8wa/ wFgwYthhnJ5XYMsePwKLMDn/pyuwCcsX5ziaOGJCcrPSxARgk5Sq0tQg/c6w8CLwUGkj 8p/g==
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=iXQO3mJ2iHtl5+ppkc+EnpSnK08ckUbrE46VWfw45zU=; b=hmjalMa5+gq+UuSX29c5qc7v58dkdwZ+5hGMHwzd8RTLnQldSJDdC3/tw4qaXFrPY4 YWq92kUKOCQhoLoK5YbLbEY8AYquX2aUSzyjDq3+eK/X3qcyczXKtKHXcre7NetnyJDz xPmjIEWnscR7TEieYGqJ2M+z9fqaDIdh+YjL+EYEjyhPaM6fN0w1Cp0WJkKeq6CeFZg5 FHZYJ6iwDdLyTNHbjwW+Q9J9N2ZMsoRYwxHKIyUOZofOaVbB5L5IiFw2RGR9r9KHBKL4 mEm1NjzoMjdLsVeE/SnBIm75tDqk6npNhEWBiEq9atMaJHyBsDrzl3DfL0qQRTRX/Ufh YK5A==
X-Gm-Message-State: AN3rC/6r+qzD8vDo8dCs8vhA4JIxiWvbqh5hG13kH0AXhZcdSfgVR7ac XvtSvAB/W6ueLKbpx9QQKjqMQmD9ausAnJ9isQ==
X-Received: by with SMTP id b71mr1313531vke.73.1492092410511; Thu, 13 Apr 2017 07:06:50 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 13 Apr 2017 07:06:49 -0700 (PDT)
In-Reply-To: <20170413031124.79969.qmail@ary.lan>
References: <> <20170413031124.79969.qmail@ary.lan>
From: Wei Chuang <>
Date: Thu, 13 Apr 2017 07:06:49 -0700
Message-ID: <>
To: John Levine <>
Cc: IETF DANE Mailinglist <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1141dd30215f3a054d0cd6aa"
Archived-At: <>
Subject: Re: [dane] domain hijacking
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Apr 2017 14:06:55 -0000

On Wed, Apr 12, 2017 at 8:11 PM, John Levine <> wrote:

> > If my suspicion is correct, has there
> >been thought of re-signing the DS record signed with the older private key
> >in a way that proves ownership through the key change?
> This sounds to me like shutting the barn door after the horse is gone.
> If it's important to you that your domain isn't hijacked, we all know
> what to do, pick a registrar with good security and 2FA and so forth,

and monitor your own DNS with alarms if there are unauthorized changes.

Even with a good registrar there might be some reason for this.  Consider
that 2FA might not  be a permanent solution to zone admin account
hijacking.  For example, RSA 2FA products which are very popular, were
reportedly bypassed back in 2012
Further such a solution might better detect/prevent spoofing by a
adversarial parent zone or registrar.  Agreed that monitoring is a good
idea.  One issue it that it may be difficult for you/your script to be
always vigilant.  Perhaps by making a domain hijacking more visible to
everyone, and having a whistleblowing (i.e. reporting mechanism such as
used in Coniks) protocol then you could distribute the problem of

> Also, if we were to invent some sort of change signing, now you have
> the other problem where the guy with the private key quits and takes
> it with him, and you have to rebootstrap the zone somehow.

Agreed this is pertinent issue and I don't have a fully baked scheme to
work out this scenario.  But perhaps a solution might involve checking the
cached but stale result to see if that historic state is consistent with a
newly published state up to 1 TTL period.  Errors condition would then
existing for a finite time (1 TTL).