Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 mapping between a (fixed-prefix + domain-specific-suffix) name and a hostname, something that syntactically could have been accomplished more simply using, say, PTR (which, contrary to common misconception, is *not* limited to reverse lookups). Personally, I would exclude Autodiscover from any list of "things which use SRV", since its use is not consistent with the spirit or the letter of the SRV RFCs. - Kevin On Wed, Nov 7, 2018 at 4:46 PM Michael J. Sheldon wrote: > > > 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 "server specific" ball. > > > > And can someone show a significant number of SRV examples outside of SIP > > and some gaming > > servers? > > From data in our systems, most common in order is _autodiscover and > other email/calendar related, then sip, then jabber/xmpp. After that, > the numbers are far less significant. > > > > -- > Michael Sheldon > Dev-DNS Services > GoDaddy.com > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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. > > This sounds like it ought to be a very unusual configuration. > > Even with a zone cut, couldn't those DB servers have been addressed as > 'db.' instead? Sure but as more than one engineer whose been using this for several years asks “why should I change? This works now and you’re just cramping engineering velocity. “ And saying “it’s not standard” doesn’t hold water. Sure there are migration issues but if folks stay in their vendor ecosystem These are the questions we as operators are asked regularly. These are the questions DNSOP need to look forward on. > >> And can someone show a significant number of SRV examples outside of >> SIP and some gaming servers? > > Kerberos and AD both use SRV records. Bonjour uses SRV extensively. I forgot about AD. Those are set up by admins right? Doesn’t Bonjour create those records behind the scenes? People are saying a domain owner is going to log into godaddy and configure a SRV record. If you want to convince me SRV will work get the vendors to support it seamlessly. > Either way, SRV is only one of three different ways that services are > differentiated (per 5507). > > Ray > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 "server specific" ball. > > And can someone show a significant number of SRV examples outside of SIP > and some gaming > servers? From data in our systems, most common in order is _autodiscover and other email/calendar related, then sip, then jabber/xmpp. After that, the numbers are far less significant. -- Michael Sheldon Dev-DNS Services GoDaddy.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 those DB servers have been addressed as 'db.' instead? And can someone show a significant number of SRV examples outside of SIP and some gaming servers? Kerberos and AD both use SRV records. Bonjour uses SRV extensively. Either way, SRV is only one of three different ways that services are differentiated (per 5507). Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 of SRV examples outside of SIP and some gaming servers? On Thu, Nov 8, 2018 at 3:48 AM Richard Gibson wrote: > 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 least tolerable—by tackling more fundamental progress > blockers. Support for covering apex A, apex , and service-specific > SRV (especially with target host addresses in the additional section of > the response) in a single transaction could absolve many sins. > > On 11/6/18 13:51, Ray Bellis wrote: > > IMHO, any record that doesn't support a service selector isn't doing > > its job properly. > > > > You _have_ to be able to say "if I want this service at this domain, I > > either prepend this prefix, or lookup this type", otherwise you're > > just forcing _all_ services to connect to the A and found there. > > > > A and should be for connecting to the right _host_, once you've > > established from the _service_ which host that is. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 least tolerable—by tackling more fundamental progress blockers. Support for covering apex A, apex , and service-specific SRV (especially with target host addresses in the additional section of the response) in a single transaction could absolve many sins. On 11/6/18 13:51, Ray Bellis wrote: IMHO, any record that doesn't support a service selector isn't doing its job properly. You _have_ to be able to say "if I want this service at this domain, I either prepend this prefix, or lookup this type", otherwise you're just forcing _all_ services to connect to the A and found there. A and should be for connecting to the right _host_, once you've established from the _service_ which host that is. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 address records have to be provisioned, to act as fallback records for clients/resolvers that don't (yet) do their own ANAME processing. (There may be some automated assistance.) That is indeed what I am aiming at, with the exception that sibling records may be provisioned to act as fallback records (they don't necessarily have to, but the ANAME algorithm may use them if they exist and if resolution of the target address records failed). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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. My point above is to do with what existing ANAME-like things expect client software to do, i.e. connecting to hosts rather than services. It isn't a judgment about what's good, but an observation about what is done. And it raises questions about trade-offs between compatibiliy with the installed base or improving things for the future. I don't have the answers :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ a fair voting system for all elections ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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) didn't recognise it as being one, and b) therefore didn't consider what would replace it. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
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 "if I want this service at this domain, I either prepend this prefix, or lookup this type", otherwise you're just forcing _all_ services to connect to the A and found there. A and should be for connecting to the right _host_, once you've established from the _service_ which host that is. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
