> On 13 Mar 2024, at 03:46, John Levine <[email protected]> wrote: > > It appears that Paul Vixie <[email protected]> said: >> -=-=-=-=-=- >> <<Rather than writing a draft for each limitation, >> >> I think it would be better to compile them all into one draft.>> > > I agree a draft describing the places where DNS evaluators > should set limits would be a good idea. > > I am considerably less enthusastic about specific limits, since > the use of the DNS has evolved a lot and some things that may > bave seemed excessive back in the day are now routine. > > The obvious example is CNAME chains. In 1034/1035 the only use > contemplated for CNAME was temporary forwarding when a host name > changed, and for that use, chained CNAMEs made no sense. Now they > delegate authority to different points of control in many different > ways. For applications like CDNs, you need two or three link CNAME > chains and nobody appears to find that a problem.
Actually it is a problem. It results in lots of additional lookups. That in turn results in amplification bug reports being reported from universities looking for the latest way to abuse the DNS to launch DoS attacks. And it is not 3 CNAMEs, you are looking at 5+ CNAMEs today. From a recent pcap CNAME XXXXXXXX.Clump.YYYYYYYY.aa-rt.sharepoint.com., CNAME ZZZZZZZZZ.Farm.KKKKKKKK.aa-rt.sharepoint.com., CNAME LLLLLLLLL.Farm.BBBBBBBBBB.sharepointonline.com.akadns.net., CNAME AAAAAAA.farm.RRRRRRR.aa-rt.sharepoint.com.dual-spo-0005.spo-msedge.net., CNAME YYYYYYYY.spo-msedge.net If you reduce the number of supported CNAMES you get “but it works with Google” thrown back at you when in reality there isn’t a need for most of this. All of the CNAMES could be done in the background rather than polluting caches with chains of CNAMES. > R's, > John > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
