Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Paul Wouters <> Tue, 21 March 2017 03:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57D381316F4 for <>; Mon, 20 Mar 2017 20:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SjQwz67HotFN for <>; Mon, 20 Mar 2017 20:08:19 -0700 (PDT)
Received: from ( [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9AA512945E for <>; Mon, 20 Mar 2017 20:08:18 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3vnHnX0g6Lzvr; Tue, 21 Mar 2017 04:08:16 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1490065696; bh=IwA5Borvaw6BegiN9FcFovWpcf4dnf/4KauQ78drRsA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LFFyjwJQ8j+UqLnmaVt+1gtv8++K9Lb3+dcbj4y+h6zM49GBpEDVL5WU0QZa8sckp e6Rn1k4CDj0+0mlpUwIwf6VKfrZiTV/zSXC5FHRuVmp1Mudycdv+xDIbFMXQptqc6Q alD29NJXVD9jMnNjI6nHSqpq2WTd7iGHmZBl9Vmo=
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id rlJCVcGFtqUu; Tue, 21 Mar 2017 04:08:13 +0100 (CET)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Tue, 21 Mar 2017 04:08:12 +0100 (CET)
Received: by (Postfix, from userid 1000) id 8CDFE39D3A1; Mon, 20 Mar 2017 23:08:11 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 8CDFE39D3A1
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78ED8414493A; Mon, 20 Mar 2017 23:08:11 -0400 (EDT)
Date: Mon, 20 Mar 2017 23:08:11 -0400 (EDT)
From: Paul Wouters <>
To: Andrew Sullivan <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
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, 21 Mar 2017 03:08:21 -0000

On Mon, 20 Mar 2017, Andrew Sullivan wrote:

> On Mon, Mar 20, 2017 at 06:19:45PM -0400, Paul Wouters wrote:
>> I am assuming that if stubs are validating, then they must also support
>> excluding special queries from validation, such as mDNS, .onion and
>> .homenet.
> What possible basis do you have for this?  This is in effect a
> requirement that every validating stub (or resolver?  I dunno) be
> upgraded to support homenet. dated October 2015 did this too:

    3.  Name Resolution APIs and Libraries: Resolvers MUST either respond
        to requests for .onion names by resolving them according to
        [tor-rendezvous] or by responding with NXDOMAIN [RFC1035].

    4.  Caching DNS Servers: Caching servers, where not explicitly
        adapted to interoperate with Tor, SHOULD NOT attempt to look up
        records for .onion names.  They MUST generate NXDOMAIN for all
        such queries.

    5.  Authoritative DNS Servers: Authoritative servers MUST respond to
        queries for .onion with NXDOMAIN.

>> The .homenet queries should never reach real DNS servers
> But they're going to.

Of course. I was just saying that when they do, there is no good answer
for them.

>> not think an insecure delegation in the root is required. If the DNS
>> resolver doesn't know how to handle .homenet, it is already as wrong
>> as it can be, regardless of the type of answer.
> This doesn't follow.  If the resolver gets it wrong in the case of a
> provably-unsigned answer, it can just continue its resolution as it
> ever wanted.  It won't be able to validate, since it does not have a
> local trust anchor.  But it'll work.

But any answer it gets makes no sense anyway, as it doesn't have the
actual required data of the real local .homenet zone. So whether you
give a NXDOMAIN or SERVFAIL or return an A record with
doesn't really matter, whether you are or

I guess the only possible exception to this is if the device in the
.homenet got multiple DNS servers from DHCP, and only one of them
and not the first one handles .homenet properly. Of course that's
a pretty broken setup to begin with, so I'm not too worried about
breaking that more.