Hello Daniel and others,
On 18. 12. 18 14:09, Daniel Suchy wrote:
> 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.
I remember from RIPE 77 meeting that there are strong opinions on
limiting what can be done and that there are reasons for that. Purpose
of my e-mail is to find out if there is a middle ground.
Does your answer mean "it is not going to happen, go away"
or is there a room for negotiation?
I can provide detailed argumentation if you are willing to negotiate.
Petr Špaček @ CZ.NIC
>
> 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/genreport.c#L216
