4 ms·

> Route 53 is a so-called "child centric" DNS server, in that it considers the child zone to be fully-authoritative for its own NS records. That's why the name

by agwa 9y ago

> Route 53 is a so-called "child centric" DNS server, in that it considers the child zone to be fully-authoritative for its own NS records. That's why the name servers for a parent zone reply with a referral, rather than in the answer, because from their perspective, they don't really "know" the answer. The proper thing a resolver should do is follow the referral and ask the child name servers. > I don't think that's in violation of what the DNS RFCs specify Agreed, and in fact it's pretty easy to see that the root and .org name servers behave exactly like Route 53 in this regard. > In any event, I think what's going in this case is more subtle but simpler, basically "ws.fdmg.org." isn't occluding "prod.ws.fdmg.org" when it should, but that takes a very convoluted edge-case set up involving two over-lapping delegations from the same parent zone. Yes, that appears to be what is happening, and it breaks regular DNS resolution, not just QNAME minimization. If your DNS resolver has the NS records for ws.fdmg.org cached because you previously looked up a ws.fdmg.org hostname, you won't be able to resolve any prod.ws.fdmg.org hostnames, because your resolver will send the queries to the name servers for ws.fdmg.org. I don't know if this is a Route 53 bug or if the customer misconfigured their zones, but if the latter it would be nice if Route 53 could stop people from shooting themselves in the foot this way. To reiterate, this breaks regular DNS resolution, not just QNAME minimization. That said, Route 53 improperly returns NXDOMAIN for empty non-terminals, which does break QNAME minimization (and violates RFC8020). For a proper example, see opsmate0._domainkey.sslmate.com and _domainkey.sslmate.com.

colmmacc 9y ago
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.

by agwa 9y ago

colmmacc 9y ago

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.