maybe its just me, but I think most of the 'add complexity' being discussed here is fruitless, and devalues DNS. Its retrofit on a simple protocol to try and cover for situations not forseen, which I believe is very often counter-productive.
We don't continue to use telnet in the wide any more, and moved to SSH. It doesn't mean that telnet option negotiations are 'wrong' but it does mean that the telnet protocol isn't the one which services the need we have any more, for telematic/interactive access services. telnet as it remains doesn't have a heap of post-2000 knobs added. If you want those features, you go somewhere else. Its been left fit for purpose in a narrowly defined role. I think the same is true of DNS. its a global label to value lookup service with a nice, small definition of the separator and the cut point, and some guidance on TTL/cacheing. We've retrofitted the beginnings of some security, but at considerable cost, and for an outcome which is now showing problems like the amplification attack effects. I think sending a stronger message about uRPF type defences, and asking other people to look at spoof source is better. Sometimes it pays to recognise you can't solve a problem, and look to who can. After all, if we reduced the amount of spoofed source, then we'd reduce attack modes in more than just DNS. the 'real' problem here isn't DNS spoofed-source attacks, its spoofed-source attacks. If for instance, somebody discovers a way to use this in HTTP and achieve a 1000x amplification, they won't just be using DNS will they? (I know, tcp doesn't work. But you get the sense of what I mean. spoofed UDP streams of video might work?) I realize it won't completely work, and that there will 'be' a problem to be solved here, and I also think that the kind(s) of solutions which increase the cost on the spoofer are probably the best we have right now, combined with some amount of probabilistic/heuristic dropping, but I still find myself thinking "this is just turning the value equation in DNS right down" We're in a world where the goal is to answer questions, quickly and accurately. The fixes are beginning to look like major attacks on that fundamental. I'm also confused about the 'no more ANY' discussion. Maybe I over-read, but I think ANY is a useful query, and I think ending it entirely would be a mistake. ANY allows for queries where you don't know the specific payload you need. DO we really want to remove that? -G _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
