Hello, I think there should be specified, which tests/options are really *necesary* for this compability testing related to the DNS flag day.
From operator perspective, you just need to know, if your implementation will have problem or if it's OK... and I think many details reported by [2] will not be even understood by normal users.
From a quick look, you're missing ability to set some bits (flags) and other options in query packet. Majority of tests in linked source code are using SOA, some other common types in query, which are already included in options available, some aren't - but they're quite exotic query types and probably not widely used - so are these really needed?
I don't think allowing "simply" anything (as you're proposing in [a] or [b] below) is a good apporach. Some options (ignoretc, for example) will not be even understood by current `dig` implementations, that's another problem. And there's always some risk of malicious use and "open" Atlas network may be misused. So I prefer to stay restrictive in terms of queries allowed over Atlas network. Daniel On 12/17/18 6:40 PM, Petr Špaček wrote:
Hello everyone,
this is follow-up from RIPE 77 hallway discussion, sorry for delay.
We are looking for ways to test DNS flag day [1] compatibility from client networks. Objective is to test hypothesis that most breakage happens on authoritative side of DNS. In other words, we would like to test that DNS recursive infrastructure and client networks do not significantly influence compatibility.
That would help to provide precise information for network operators who will have to deal with DNS flag day.
Problem here is that RIPE Atlas does not allow to send all types of queries [2] required for full test. It was discussed at length that Atlas team has its reasons for not sending random blobs to random IP addresses, which is understood.
Question here is: Can we find a middle ground to allow greater variety of valid DNS queries without forcing Atlas team to reimplement everything?
My notes from meeting mention two approaches for further dicussion:
a) User provides command line arguments for well-known tool dig, which gets executed in controlled environment ("as part of RIPE Atlas infrastructure") and generates query packet/blob. This blob generated by dig is then used as payload so use cannot ship anything but syntactically valid DNS packet.
b) User provides blob for payload, which is then analyzed by packet parser of choice (BIND/ldns/Knot DNS/all of them). The payload can be sent out only if packet parsers do not find out any problem/blob is syntactically valid.
These two approaches can also be combined to guard again quirks in either component.
c) <propose your own here>
What do you think? Is there a way to allow greater flexibility to Atlas DNS?
[1] https://dnsflagday.net/ [2] https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/blob/master/genre...