On 7/4/19 5:39 PM, Matthew Pounsett wrote: > > > On Thu, 4 Jul 2019 at 10:54, Matthijs Mekking <[email protected] > <mailto:[email protected]>> wrote: > > Matthew, > > > I would say they should rely on that. Why shouldn't they? Isn't our > > goal to get downstream servers to adopt the extension and do their own > > lookup? The server-side lookups and sibling records are bolt-ons to > > handle the adoption period. Remember, this record is geared toward > > customers of CDNs being able to do get similar behaviour to: > > www.example.com <http://www.example.com> <http://www.example.com>. > IN CNAME webfarm.cdn.net <http://webfarm.cdn.net> > > <http://webfarm.cdn.net>. > > at the apex of example.com <http://example.com> > <http://example.com>. That was the original > > problem we're trying to solve. I read your statement above about "the > > service they provide their customers" being about the CDN resolving > > webfarm.cdn.net <http://webfarm.cdn.net> <http://webfarm.cdn.net>, > which most CDNs can already do > > within their own infrastructure. > > I am talking about DNS providers that perform CNAME at the Apex like > features: a customer goes to them and opts in to this feature. Such a > provider wants to make sure that it is providing the behavior the > customer expects and thus wants to make sure it hands out appropriate > addresses. > > > And "CNAME at the Apex like feeatures" is to hand out a CNAME and let > the downstream server process that. It may include additional > information from other zones it is authoritative for, but it doesn't do > side-lookups. I think that's the behaviour we should be aiming for, and > to do that some sort of "I understand ANAME" signal would allow the > authoritative server to behave more like CNAME.
I agree we should be aiming for that, but initial stage will very likely be that authoritative servers will do the target lookups (otherwise we could just deploy the HTTP record right now ;)) > Also what is wrong with an authoritative server already giving out more > optimal answers than just the ANAME and sibling address records? > > > Nothing, as long as it's not going to increase the time it takes to > respond to the query. > > But, you didn't respond to my question. Let me rephrase it a bit: If > the authoritative server knows the client understands ANAME, why would > the authoritative server not assume that any additional data it supplies > will be thrown away? I suggest that it would be wise for an > authoritative server to assume that a client that understands ANAME will > resolve its own ANAME and ignore any other data it gets. I sure hope not that requester will throw away responses, why else is it querying the servers in the first place? ;) The sibling address records that the authoritative server provides are needed if the requester does its own ANAME target lookup but fails to do so because of an outage for example. Then it can use the sibling address records as the response to the client. It would be better if those are already "ANAME processed" rather than just handing out the sibling records that were available in the zone file. So it may be a poor judgment if the requester just throws away the answer the authoritative server sends. > > Option #2 gets similar behaviour but at the cost of additional > lookups. > > #3 and #4 don't work well in the presence of server farms. > > If addresses are in the response to the ANAME request there is no > difference in number of lookups between 2 and 3 I think. > > > Did you mean "lookups between 1 and 2"? I didn't say anything about > the number of lookups required for 3. I think 3 and 4 are poor choices > because they won't behave well with most server farms. Yes, 1 and 2. Sorry. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
