Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-08 Thread Kevin Darcy
It should be pointed out that the Autodiscover subsystem of Microsoft Office uses SRV in a very *degenerate* way. It ignores all fields other than target. In my testing, I believe I also proved that it doesn't fail over if presented multiple SRV RRs in a response. So, basically it's a one-to-one

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-07 Thread tjw ietf
From my high tech gadget > On Nov 8, 2018, at 06:30, Ray Bellis wrote: > >> On 08/11/2018 04:13, Tim Wicinski wrote: >> >> I can't stress this enough - when you see ALIAS records at zone cuts >> that point to a database server, already, then we've missed the >> "server specific" ball. > >

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-07 Thread Michael J. Sheldon
On 11/07/2018 02:13 PM, Tim Wicinski wrote: > Tony says this: > > " It isn't a judgment about what's good, but an observation about what > is done." > > I can't stress this enough - when you see ALIAS records at zone cuts > that point to a database server,  > already, then we've missed the

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-07 Thread Ray Bellis
On 08/11/2018 04:13, Tim Wicinski wrote: I can't stress this enough - when you see ALIAS records at zone cuts that point to a database server, already, then we've missed the "server specific" ball. This sounds like it ought to be a very unusual configuration. Even with a zone cut, couldn't

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-07 Thread Tim Wicinski
Tony says this: " It isn't a judgment about what's good, but an observation about what is done." I can't stress this enough - when you see ALIAS records at zone cuts that point to a database server, already, then we've missed the "server specific" ball. And can someone show a significant number

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-07 Thread Richard Gibson
This is such a salient point, and always draws me back towards a desire for accompanying questions. They wouldn't directly address exactly the issue handled by ANAME (the addresses of one host corresponding to those of a distinct [probably out-of-bailiwick] name), but might make it moot—or at

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-07 Thread Matthijs Mekking
On 11/6/18 6:28 PM, Tony Finch wrote: But thinking about the discussions from the weekend and yesterday, it occurs to me that it might make sense to simplify ANAME even further: * Make all authoritative processing optional, whether UPDATE style or dynamic on-demand. * The sibling

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-06 Thread Tony Finch
Ray Bellis wrote: > On 07/11/2018 00:28, Tony Finch wrote: > > >* General purpose (also works for ssh, databases, etc) vs HTTP-specific > > I just wanted to address this particular point, again. > > IMHO, any record that doesn't support a service selector isn't doing its job > properly. Yes.

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-06 Thread Ray Bellis
p.s. anyone thinking a new _generic_ resource record is required, please (re)read RFC 5507. HTTP started off with a service identifying prefix, but it was merely by convention, and it was "www." This whole mess started because folks wanted to get rid of that service identifier, but a)

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

2018-11-06 Thread Ray Bellis
On 07/11/2018 00:28, Tony Finch wrote: * General purpose (also works for ssh, databases, etc) vs HTTP-specific I just wanted to address this particular point, again. IMHO, any record that doesn't support a service selector isn't doing its job properly. You _have_ to be able to say