Re: [Doh] on blackholing and

Ted Hardie <> Wed, 27 March 2019 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 854EE120526 for <>; Wed, 27 Mar 2019 06:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hezzLTJeLm9U for <>; Wed, 27 Mar 2019 06:22:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 306DB1206D8 for <>; Wed, 27 Mar 2019 06:22:02 -0700 (PDT)
Received: by with SMTP id c4so13997880ioh.9 for <>; Wed, 27 Mar 2019 06:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5pSuM71iyYzRveYiKmGOwNen1SM1YFmI75u9jCnqtZk=; b=ep6iMQqaY54sDIwto5kqSmehjAcN5LahqdVmnQuTPiVgTXopt6BOafKcMn7/1a3QaH hIuc9/ckOaZYU5KTzZMXQ4qjU9pbWsuk2uml5rL+mANTBscLGXzXj+2MAdadaxHPOBOi QoPZAq7WoSy8vKlWtazmspYod5CCT+OALma+L4E2Eyq3LolVIhW6LgNIfHotoq6oUrlz VMoN5kyNZH19bU6Ue99DT2mtJFnjmQbEMX1iMsoHXUQo8uSfXkhO58tN1RhSjthUsnMM PNBiYzq3RWmGiJas217cZkwpHetR53PxdtRBbPjDAy5duuEAzl2J4/1O+VoqPxBI3IAK 40QQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5pSuM71iyYzRveYiKmGOwNen1SM1YFmI75u9jCnqtZk=; b=BSzr7pAqGxIteTbqluHx5C+MrR+tDVHDmCI7lwQyR/4ULYjxGRwokcRh6cozccu/bq mFh9r3YI89B+/o/XyTYraKhd04E0OPlCKR4Oodb+/1ufSXkFuq+B2d1b1i6pZi3uBPUN H6Qy0k16paWxMEkkU/ToeUiT+kzDbPwMJhCnWBWDZ6DJLWVM+LZakaiEFzIs5RNVhnU2 6i8K2aGUntHOGxvdLEI0Ev/cy93emRiqP9qsu50iCXw6kVFdkbbgbvguRMOjLNAllVxS DiyslUFCbqijtOhh+v8i2LZDj8rRO08FVx8AEir3UvhZp6M6PzN1z0FtOUdtNwawisMt VGhg==
X-Gm-Message-State: APjAAAX1wvrwaOXx9rVYhg9TXz7g4QxCr1i7Y1x1HFDknxQjJB42TMOZ ZumEPQktuf3F+u0L+aD+rXQ3x4+fRclm3ByMYYQ=
X-Google-Smtp-Source: APXvYqzGfs7CB9iuRJKLPkAarAJ8tTH1tP6sFtuii1kz8mcg+2PvIYk9vjlL3MAHIezvTbLt3nfzrN4AihKcJfavuoI=
X-Received: by 2002:a6b:e202:: with SMTP id z2mr25516819ioc.6.1553692921276; Wed, 27 Mar 2019 06:22:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ted Hardie <>
Date: Wed, 27 Mar 2019 14:21:34 +0100
Message-ID: <>
To: Joe Abley <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000a9c398058513520a"
Archived-At: <>
Subject: Re: [Doh] on blackholing and
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Mar 2019 13:22:13 -0000

Hi Joe,

Top posting, forgive me.  I recognize that this is different from junk PTR
case, but I would interested in how different you see this from the case laid out in RFC 8375?  The critiques you make seem to
indicate that you would have similar issues there, but if there is a
distinction (e.g. single answers versus declared resolver), it would be
useful to draw it out.



On Wed, Mar 27, 2019 at 11:30 AM Joe Abley <> wrote:

> Hi Ted,
> On 26 Mar 2019, at 16:31, Ted Hardie <> wrote:
> When I sent the text (as requested), I just grabbed a copy of the text
> from  RFC 8375, Section 7.  That suggests pointing to '
>' and ''  which the AS112
> project augments.  The issue that these were built to solve, a high load of
> queries to .arpa for queries leaking into the zone, seems like it might
> apply to this special use name.
> I am familiar with the AS112 project. The crucial difference between the
> junk PTR queries for RFC1918 and RFC1918-like nets that are soaked up by
> those servers and the two ARPA domains we're talking about here are that
> the threat models are very different. It's a stretch to imagine that a
> rogue PTR response can cause anybody any harm, whereas a rogue response to
> these doh queries could subvert all subsequent name resolution in a way
> that would be difficult to detect, and there is the potential to do so on a
> large scale.
> DNAME is theoretically possible instead, but the .arpa server operators
> have historically been slow to take up the idea of using DNAME (they did
> not agree for  I have no objection to trying again, of course,
> if that is preferred.
> My DNAME observation was simply to illustrate that the blackhole idea was
> inconsistent with the current text in the document. I'm aware of the
> practical problems of using DNAME in ARPA in the way that it is currently
> managed.
> I agree that there is a possible issue here, and I would support
> documenting it.  But since the basic trust model I'd suggest for a doh
> server discovered this way is equivalent to "something scrawled on the wall
> of a coffee shop", I think this situation (in which they are not recognized
> locally as special use names, and the particular anycast AS112 server
> answering the leaked query is an attacker) is pretty much par for a pretty
> rough course.
> I think the risk is far more serious than you are implying, and to be
> honest I think the only useful advice here is that the mechanism should be
> considered harmful and must not be used.
> Since the meeting this week also seemed to expose concerns about the other
> two mechanisms, it's seems possible that this draft has led us down a dead
> end.
> Joe