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