-----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-----