On Thu, 4 Jul 2019 at 05:54, Matthijs Mekking <matth...@pletterpet.nl> wrote:
> > > > 1. EDNS "do not follow ANAME" option: The requester would indicate > > that it is capable of following ANAME and that the server receiving > > the query should not include the ANAME sibling address records. The > > loop detection would then work exactly the same ways as with CNAMEs. > > This would be an easy addition I think, however I thought the "do not > follow ANAME" option actually meant "really don't do a target lookup I > can do it myself". The authoritative server can still send the sibling > address records that are placed in the zone, they can be used if the > requester fails to perform the ANAME target lookup (for example due to a > network error or outage). > > Furthermore, a service provide receiving such a request might want to > ignore it if it feels strongly it should hand out more appropriate > addresses than the sibling records (basically because that is the > service they provide their customers, will they rely on an EDNS option > from the requester saying "no really I can do this"?). > 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. IN CNAME webfarm.cdn.net. at the apex of 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, which most CDNs can already do within their own infrastructure. Sending out the sibling records in the presence of this EDNS option might make sense as a backup, since that is low effort on the part of the authoritative, but a declaration by the querying server that it understands ANAME and is prepared to do its own lookups should be trusted by the authoritative server, and it should not to recursive lookups. To take that further, why would the authoritative server believe that the results of any lookups it does would not be thrown away? This EDNS option should also be useful to recursive servers that understand ANAME, and are planning to do their own ANAME resolution. They can get their answer from the authoritative server much faster this way. This is also a way to measure adoption. As the ratio of "EDNS do not follow ANAME" queries to total ANAME queries approaches 1.0, we know that adoption has been successful. Maybe we could even begin to deprecate authoritative resolution (of ANAMEs) at that point, and begin to get back to something that looks more like plain CNAME. I would suggest that better EDNS semantics would be just "I understand/support ANAME". That gets the desired information across without the sense of sending a command to the upstream server. 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
