Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Doug Barton <dougb@dougbarton.us> Wed, 07 January 2015 17:27 UTC

Return-Path: <dougb@dougbarton.us>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EC61A0055 for <ietf@ietfa.amsl.com>; Wed, 7 Jan 2015 09:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.412
X-Spam-Level:
X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_74=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB_92SV2wn7S for <ietf@ietfa.amsl.com>; Wed, 7 Jan 2015 09:27:33 -0800 (PST)
Received: from dougbarton.us (dougbarton.us [208.79.90.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909181A004B for <ietf@ietf.org>; Wed, 7 Jan 2015 09:27:33 -0800 (PST)
Received: from bcn-dbarton.lan (unknown [67.159.169.102]) by dougbarton.us (Postfix) with ESMTPSA id 83E6E22B13 for <ietf@ietf.org>; Wed, 7 Jan 2015 17:27:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1420651652; bh=Xp/ISXsWvxicfIF1Xzj7OaVwyqWcklth+fyrZA4rbHw=; h=Date:From:To:Subject:References:In-Reply-To; b=HwDG48I9XFgTiWuFdD0aUuGxg6PRbEMrTHhtDAU6Iint1h39zFkzObdDakI+4GgEL SAmBygzi8VasSfaLh96FsaR5XtoflrEPMLGMjjU5uFBb8TdYGooY8KXm3uZdbbHQ4n l/ISJc9tUFRV/NkuXClrWES4Mj8nPPTC/B2Mov84=
Message-ID: <54AD6C82.2050105@dougbarton.us>
Date: Wed, 07 Jan 2015 09:27:30 -0800
From: Doug Barton <dougb@dougbarton.us>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
References: <CAK3LatFh3ZU8ACk8grzLA9oCv2qqUHttz2z83b66xKnfs78mRA@mail.gmail.com> <54A7DBFC.8010800@cisco.com> <20150103143226.GC13599@besserwisser.org> <89DB2965-68B1-43D0-BBEB-FF49DB666A6D@frobbit.se> <54A81E9A.1020700@cisco.com> <20150103215310.D533D26FFFCD@rock.dv.isc.org> <54A8F75B.80007@cisco.com> <20150104122310.GF13599@besserwisser.org> <20150106000707.E3B7C2707D90@rock.dv.isc.org> <54AD2850.5090905@cisco.com>
In-Reply-To: <54AD2850.5090905@cisco.com>
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/dK5kkHFyRnMGWoqNV21SJ0kPrnU
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jan 2015 17:27:35 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 1/7/15 4:36 AM, Eliot Lear wrote:
| Hi Mark,
|
| On 1/6/15 1:07 AM, Mark Andrews wrote:
|> Or one can delegate _http._tcp.example.net back to the
|> servers for example.net or delegate it to the hosting
|> provider and they can update the SRV records.
|>
|
| No doubt, and there are all sorts of other things one CAN do.  One
| common configuration is for enterprise AD servers to be delegated _tcp
| for any number of reasons.

That is generally true on the *internal* zones, if the enterprise has
made the mistake of using their publicly facing domain for their parent
AD zone instead of following the MS best practice of using a subzone
like ad.example.com, or a private zone like example.corp.

It is almost universally true that this same damage does not extend to
the *external* DNS, which is what is under discussion here. *

| Operationally this happens, and in large
| sites it is not uncommon to see TCP-based queries because of it.

I'm not sure how to parse this sentence.

| How wide scale is the issue

... as above, this issue is virtually non-existent in the external DNS
space. I wish I could say that I've never seen a customer whose
configuration prior to our involvement leaked their AD-related zones
publicly, but the actual number is way less than 10%. *

It's also worth pointing out that we're talking _http._tcp and
_https._tcp, which could theoretically be delegated as separate zones,
so even in the most brain-damaged cases, this issue can be resolved
without the direct involvement of the AD DNS.

| and is any performance hit acceptable?  That is
| a fair question and difficult to answer.  It would be perfectly fine
| with me if the WG had said, “ok, we'll just manage that delay; records
| cache anyway.”  But that is not how discussions went.  Delay is
| important.  But here again, I think we could use more analysis.  That
| shouldn't hold up this draft, however.

Unfortunately the HTTP literati decided over a decade ago that they
would not consider SRV under any circumstances, and that position hasn't
changed in spite of it being proven repeatedly that there is no basis in
fact to their assertion that it would result in a performance penalty
(and in spite of being asked several times in the intervening period to
reconsider, including by me personally at the opening of this latest WG).

Doug


* I hate appeals to self-authority as much as anyone, but this is what I
do for a living, and I am our company's expert on taking over DNS from
MS DNS, including AD DNS.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJUrWyCAAoJEFzGhvEaGryESKsIAJJBMDJaIQi6/iwyMpYKbt++
XBSTVjoKc111JYJZGti1NGluiDlTFkNkzYwx73UTYqae4E8m7hLxZ3X5qPnPp02l
+pC5R8FgCNbqcECFTmJE6Fe3J1L3UyDvR7GD0C8wUeFjLOIWufIZ6k8UWU7P6ZKw
GMnX7tLe9F1tVK9n5RHU6gaiHfSAFQXPIAOo/ueBYGqwReh7tC5vjROWTeGW04Zz
S4VwJ9+IjPnGDlB5PBMeGFcUyCQregigEvU1rYvQPFZLn/Ty4TXLCR+7xLlVfUvf
dqvXRuHJDsbwH+HoaH9AvoPfSBo+kgJ6NUUndZuULv6/nDcMxc1/TGJGh7+JBu4=
=vEal
-----END PGP SIGNATURE-----