[ratelimits] Remarks regarding the Knot DNS 1.2.0 RRL implementation

[Joe Abley]

On 2013-03-06, at 09:39, Vernon Schryver <vjs at rhyolite.com> wrote:

>>> I wish there was an option to have
>>> 
>>> - exactly Vixie/Schryver RRL on NSD
>>> - exactly Vixie/Schryver RRL on knot
> 
> How close to the BIND9 RRL code do the other version need to be?

I have not studied any of the implementations beyond watching math scroll past on this list, and so this is a non-detailed answer. Really, I want the operational experience to be as similar as possible. I want the same query traffic when presented to any of BIND9, knot or NSD to cause response behaviour that is sufficiently similar that people running any of those nameservers can share operational experience and have high confidence that we're comparing apples with apples.

Maybe that's reality today, but since the codebases are all independently implemented, there are in some cases different configuration knobs and since I see list traffic about differences in approach, I don't have that confidence.

Could Nominet, ICANN, Afilias and others dump pcaps + RRL config + logs from NSD, knot and BIND9 in adjacent directories on a DNS-OARC server today and expect the same analysis across all available data to produce useful results?

Independent implementations of core DNS software make sense to me. It's an established protocol and diversity of approach provides useful protections against software defects in individual products.

RRL is experimental and new. There is little established understanding of the behaviour of the underlying logic in the wild (at least, when compared to the understanding of how the core DNS protocols should work). Independent implementations of RRL at this stage in the game therefore make little sense to me.

I would like to see a single RRL code base applicable to those three DNS servers being worked on concurrently by as many people who can contribute so that it can be refined and its behaviour can be better understood. I appreciate this may be difficult given the internal differences in the products that RRL needs to glob onto. I also want a pony. (I don't actually want a pony. Don't send me a pony.)

Once we reach the point where there is widespread understanding of what RRL is doing I can see value in other approaches and options appearing in different packages. But I don't think we're there, yet.

Today, I don't think our operational understanding of the impact of RRL or NSD-RRL or knot-RRL extends much beyond "we were being used as a reflector, so we turned on *-RRL with the defaults, and our outbound traffic dropped, hooray". Many of the operators we've heard from run root servers or TLD servers. I think we want more understanding, and I don't think we get there with everybody running similar-but-different code.

I realise this is a high-level, general answer to your specific questions, but perhaps it adds some small clarity to the point I have been trying to make.


Joe