On Fri, Mar 29, 2019 at 9:58 PM Tony Finch wrote: > There were several useful points at the mic; thanks Paul Hoffman for > noting them in the minutes (especially because I could not remember who > said what). In no particular order...
Tim also mentioned that the vendors have their own secret sauce for handling the ANAME-like records. Let me share some details about the NS1's ALIAS record implementation. I hope it will be helpful when thinking about the remaining edge cases and also as an input for new implementers. The most significant difference from the current draft is that sibling A/AAAA records have precedence over the ALIAS record. I think this behavior is closer to how CNAME is usually processed by a DNS server (i.e. first try to match the QTYPE then check if there is a CNAME) however I don't find this reasoning determinant. One advantage is that you can configure static AAAA record and use ALIAS to resolve only the A. The ALIAS records are resolved by our edge servers when needed and the result is cached. Nothing is written into the zone. We always resolve both A and AAAA at the same time and use the minimal TTL of the A and AAAA to determine how long to keep the result in the cache. The current TTL is also used in the answers (i.e. you will see the value drop when querying the same server several times). Also, if A nor AAAA exist at the ALIAS target, our authoritative server responds with SERVFAIL to indicate misconfiguration of the record. The ANAME from the draft would result in NODATA. We prefer SERVFAIL as we don't want the resolver to cache NODATA if there is an interim problem resolving the ALIAS target. Last but not least, we strip ALIAS from zone transfers. I guess that's all about the "secret sauce". We would like to move from ALIAS to ANAME when the draft becomes stable and other implementations start to emerge. The critical change for us is likely the A/AAAA vs ANAME priorities. In case the primary server adds sibling A/AAAA to the ANAME for compatibility with old resolvers, our implementation would always use the fallback records and ignore the ANAME if the zone was ingested over a transfer. We also have existing users that rely on the current behavior and we have to check that we won't break their setup if we change anything about the processing. I believe this aspect of sibling A/AAAA was already discovered in a context of "zombie records" mentioned in https://github.com/each/draft-aname/issues/25. There will be some challenges but I'm really happy that ANAME is happening. Jan _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
