Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

Ted Lemon <> Tue, 03 April 2018 17:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1116B126C83 for <>; Tue, 3 Apr 2018 10:55:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 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, 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 CZXpulyKmOJX for <>; Tue, 3 Apr 2018 10:55:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC28A1243F6 for <>; Tue, 3 Apr 2018 10:55:00 -0700 (PDT)
Received: by with SMTP id b198so19533034qkg.9 for <>; Tue, 03 Apr 2018 10:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=eHZHyyL87HoRXFan0SSWyXkSgNt41cguc3huX8tuefE=; b=Mq6eLfIdURFeEnxgLOHSn84iX5Bdq3ZK4bOutQR0/0DkaZvy8LGQGZgngtwK17rTto TqVSqoCAVq30Pag2xT0ZzuFFr0VhjhwibBXjKuULI/H+sxeP6Wyy8d68aTSj3P/cGZbe 9kJ0lvzS835Rlw0k2/5UNb/VHcSGA/4Cs1TTh1rzu3zwsnM4P/OhEs/5rISmP4MfLhhg UzMxxjOy8E+/aI8BEW2vf4vy7d1jAjzeSqlTQVaPrWs1c9UBikxjYeFPHRrUh3Okv3Y+ 7DoqkymIe6B6qTo2tTPTFCJdW9YEkaJQzX6KpL83JKxSsvQ+CzMFQ0f827/WwLpcQkG3 m0gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=eHZHyyL87HoRXFan0SSWyXkSgNt41cguc3huX8tuefE=; b=uHwd8zTdWGRwfIRc0fdBtqYa79xHtZdkiulAO53g29MwRst0TDah7Jkwgg0NzzMvEB /xOWmh41neMt6j4mvFuAYiEEIXV5iKQX4PQSUKJt4DU29xUT97K65mbjQWclDRT0VR4h rBukwA/swLcKKwB6scsQs++x/SU/aknxluAIDLaDa3nawbeHQbUhTUvGYB78y1fj9S5c JGjLhhXE3SBFp3yllj8f+BiEuRvR69FdjINNts4QopdFOSsXIWuqnavNQdvSjYXIaKf7 9ydMh3GQ6zYGMlrLyvSqHsn11zlbw/ppEsKDf+uyYV5YQrm+emNa2kCkpasoefRwRh06 3RGw==
X-Gm-Message-State: ALQs6tDMqp9iUWoQ42nOSjcIpqBo6F6Y+xpGcCM1zBqmT8Nhu5nu0B/q fGDf/uT8GhaJbKTQZSYuk+AnmA==
X-Google-Smtp-Source: AIpwx48T8y7CFUurKkSzhxOCSLL+wN23AXxQB4fc68c6l38EXrqxlWCY0G6gvAmUGD2qluntV9MNEw==
X-Received: by with SMTP id z20mr20239167qkb.246.1522778099959; Tue, 03 Apr 2018 10:54:59 -0700 (PDT)
Received: from cavall.lan ( []) by with ESMTPSA id m3sm2762856qtb.32.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Apr 2018 10:54:58 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_51EDEACF-5C87-40FA-AABC-FF275DB72CE6"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Tue, 03 Apr 2018 13:54:57 -0400
In-Reply-To: <>
Cc: dnsop <>
To: Dave Lawrence <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [DNSOP] [Doh] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http
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, 03 Apr 2018 17:55:03 -0000

On Apr 3, 2018, at 1:00 PM, Dave Lawrence <> wrote:
> That testing TCP capabilities part is a distraction from the core
> motivation.  The request makes sense from a dumb transparent proxy
> point of view, where there's a regular DNS resolver on the one end who
> just wants to be able to get DNS messages through an HTTPS tunnel.
> Media type isn't the right way to achieve that, but the key idea is sound.

This didn't actually clear things up for me.   I think that what you mean is that you don't want the tunnel server to do truncation detection and retry over TCP—is that right?   If so, that's a point worth discussing explicitly.   I think you could make arguments for both positions. Given that you're doing DNS-over-HTTP-over-SSL-over-TCP here, the tunnel server definitely could do truncation detection and retry, and that would probably perform better.   Also, if it's a DNS server that's just consulting its cache, doing truncation is just a waste of time.

But possibly I misunderstood your point?