RFC8020 is an example of the DNS WG making backwards incompatible changes. The "NXDOMAIN" for an empty non-terminal has long been the behavior in DJB's TinyDNS.

RFC8020 is an example of the DNS WG making backwards incompatible changes. The "NXDOMAIN" for an empty non-terminal has long been the behavior in DJB's TinyDNS. That isn't what Route 53 is using, but I bring it up because there have been mailing list threads (or flames?) where folks complained about what DJB's software is doing, and he repeatedly asked "Show me where in the standards this is is specified or forbidden?" and no-one would come up with the goods, but folks still basically wanted "Just do what bind does". Here's DJB's own mail about it, I had to forward it because his mails don't get through to the mailing list for some reason (that might be the fault of his own stupid qsecretary moderation system): https://www.ietf.org/mail-archive/web/dnsext/current/msg11084.html https://www.ietf.org/mail-archive/web/dnsext/current/msg1108... I generally sympathize with DJB in this case, because DNS really needs some robust and competing implementations. The standards should be tolerant of differences in behavior (as others are), rather than dominated by the proponents of one implementation. It doesn't help that the WG is toxic, at least in my opinion as someone who has been reading it (and mostly just reading) for over a decade. Anyway, I'm not trying to start an argument, just explain. In this case, the bind proponents did dominate, and we get RFC8020, which for some software is a backwards incompatible change. This isn't the first backwards-incompatible change either. The invention of DNAME introduced a new kind of backwards-incompatible occlusion, and name servers "before" and "after" DNAME respond in different ways, for the same zone file. Those kinds of changes place providers in a pickle: one of our golden rules is never to make backward incompatible changes or break anything that was working. A promise is a promise. So it means we have to lock things down (the previous paragraph is the reason Route 53 does not accept arbitrary literally-encoded RRs) and when changes come; either not make those changes, or exhaustively audit and determine how many zones, queries it might impact and whether that would change anything. At scale, you'd be amazed how small and subtle behaviors can end up being embedded as assumptions in customer scripts and so on.