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/genreport.c#L216
--
Petr Špaček @ CZ.NIC
