> I disagree with the rationale for 13 name servers. > > The root (and .com) have that because it was what would fit into > packets of a particular size given their naming scheme and that > scheme's efficient compressibility. > > If there is to be a recommended limit, it should be specifically > for packet size reasons, and not just "because this is what the > root does".
In this case, what the root does is a minimum otherwise things would break. But there is more at play than packet sizes. From a packet size point of view the limit on RRsets is around 64 KB per RRset. For CNAMEs, all CNAMEs plus the result RRset need to fit in 64 KB. For delegations, all NS records plus required glue need to fit, etc. However those limits provide an opportunity to completely DoS a recursive resolver. No recursive resolver just keeps following CNAMEs until a 64 KB limit is reached. So in practice recursive resolvers have far lower limits on the number of CNAMEs they are willing to follow. So what we see is that some names cannot be resolved by some resolvers because the CNAME chain is longer than what the resolver accepts. Currently, security researchers seems to have a hard time finding interesting bugs in DNS software so they mainly focus on DoS attacks. The net result is that for recursive resolver software, there is a push to reduce the limits of what the resolver accepts. When the limits get to low, things start breaking. So the question becomes, do we want some limits in an RFC that everybody agrees on or do we want to keep the current informal system where limits are not fixed and people can get unlucky if they exceed limits they didn't know exist. _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
