Support for arbitrary DNS queries
I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. Is this feasible? Are others interested in this capability? Thanks! Shumon Huque
On Wed, Dec 09, 2015 at 10:49:09AM -0500, Shumon Huque <shuque@gmail.com> wrote a message of 26 lines which said:
I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API.
By the way, this (real) limit does not seem to be documented in <https://atlas.ripe.net/docs/measurement-creation-api/> which does not indicate the possible values for query_type.
I'm particularly interested in newer DANE reacord types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful.
A partial workaround is to use ANY as a query_type.
Is this feasible? Are others interested in this capability?
Count me in.
On Wednesday, December 9, 2015, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Wed, Dec 09, 2015 at 10:49:09AM -0500, Shumon Huque <shuque@gmail.com <javascript:;>> wrote a message of 26 lines which said:
I'm particularly interested in newer DANE reacord types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful.
A partial workaround is to use ANY as a query_type.
Not necessarily: https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00#section-8 and http://blog.cloudflare.com/deprecating-dns-any-meta-query-type/, for example.
On Wed, Dec 09, 2015 at 08:51:21PM +0200, Micha Bailey <michabailey@gmail.com> wrote a message of 48 lines which said:
A partial workaround is to use ANY as a query_type.
Not necessarily: https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00#section-8 and http://blog.cloudflare.com/deprecating-dns-any-meta-query-type/, for example.
I know the semantics of ANY, thanks :-) That's why I called it a "partial" workaround.
I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful.
Is this feasible? Are others interested in this capability?
definitely! both for research and for monitoring my own services. randy
On Dec 9, 2015, at 2:39 PM, Randy Bush <randy@psg.com> wrote:
I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful.
Is this feasible? Are others interested in this capability?
definitely! both for research and for monitoring my own services.
Perhaps a method to just set the RRType as integer would work in the interim? - Jared
On 2015-12-09 20:53, Jared Mauch wrote:
On Dec 9, 2015, at 2:39 PM, Randy Bush <randy@psg.com> wrote:
I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful.
Is this feasible? Are others interested in this capability?
definitely! both for research and for monitoring my own services.
Perhaps a method to just set the RRType as integer would work in the interim?
- Jared
Thank you for everyone who chimed in so far on this topic. This feature is on our radar, or short-list if you will (and I'm sure it'll appear on the public roadmap shortly ;-) Paraphrasing what we have as description / todo internally for the actual feature (Jared: bingo!): "[once implemented] simple DNS measurements can happen just like they do today: I can select a DNS query type by mnemonic. The new feature is about advanced DNS measurements: users should be able to specify a DNS type ID (numerical value, 0-65K) which is checked against a whitelist" We plan to have a whitelist [of query IDs], both because the probes just don't fully support all types, and some users expressed that they would not like us to support all query types; for example axfr/ixfr are complicated examples. Regards, Robert
Op 09-12-15 om 21:58 schreef Robert Kisteleki:
We plan to have a whitelist [of query IDs], both because the probes just don't fully support all types, and some users expressed that they would not like us to support all query types; for example axfr/ixfr are complicated examples.
And sending arbitrary EDNS0 options? Have you ever considered that too? Is it on the todo list too? Thanks, -- Willem
Regards, Robert
On 2015/12/10 10:11 , Willem Toorop wrote:
And sending arbitrary EDNS0 options? Have you ever considered that too? Is it on the todo list too?
Hi Willem, Just about all EDNS0 options take parameters. It is not part of the model to allow users to inject arbitrary binary data. Though if there is sufficient interest, we can add some of the options currently proposed (cookies, keepalive) Philip
On Dec 10, 2015, at 6:21 AM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2015/12/10 10:11 , Willem Toorop wrote:
And sending arbitrary EDNS0 options? Have you ever considered that too? Is it on the todo list too?
Hi Willem,
Just about all EDNS0 options take parameters. It is not part of the model to allow users to inject arbitrary binary data. Though if there is sufficient interest, we can add some of the options currently proposed (cookies, keepalive)
client-subnet? :) - Jared
On 2015/12/10 13:33 , Jared Mauch wrote:
client-subnet? :)
I can add an option to send 0/0 as the client subnet :-)
On Thu, Dec 10, 2015 at 2:33 PM, Jared Mauch <jared@puck.nether.net> wrote:
On Dec 10, 2015, at 6:21 AM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2015/12/10 10:11 , Willem Toorop wrote:
And sending arbitrary EDNS0 options? Have you ever considered that too? Is it on the todo list too?
Hi Willem,
Just about all EDNS0 options take parameters. It is not part of the model to allow users to inject arbitrary binary data. Though if there is sufficient interest, we can add some of the options currently proposed (cookies, keepalive)
client-subnet? :)
- Jared
Is this really useful? I mean, if a DNS server honors client-subnet, then it doesn't really matter which node is making the lookup. you might as well loop over your local machine and change the client-subnet. what could be very interesting though, is to map DNS servers supporting EDNS0 and ones not supporting it (i.e. which network operators should be bugged to support it...). it would be very good for network operators to see e.g. in-country adoption rate before relying on a CDN using EDNS0 as the core POP routing technology.
On 2015/12/10 13:43 , Gil Bahat wrote:
what could be very interesting though, is to map DNS servers supporting EDNS0 and ones not supporting it (i.e. which network operators should be bugged to support it...). it would be very good for network operators to see e.g. in-country adoption rate before relying on a CDN using EDNS0 as the core POP routing technology.
Mapping EDNS0 support can be done today. There are the various DNSSEC related flags and udp payload size. And probes can prepend their probe ids so you can see at the dns server which probe is which.
actually, It would be extremely useful for the DNS probe results to immediately and clearly reflect whether any response included EDNS0 bits or not, without this being a separate test. I am trying to debug some oddball CDN DNS assignments and this means trying to hunt down specific probes and tweaking specific lookups in order to get this... inconvenient to the point of almost unusable with that regards. something like this is a quick hack to achieve it: https://www.dns-oarc.net/oarc/services/replysizetest yet, it's much better to have it built-in. Regards, Gil Bahat, DevOps and Network Engineer, Magisto Ltd. On Thu, Dec 10, 2015 at 2:54 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2015/12/10 13:43 , Gil Bahat wrote:
what could be very interesting though, is to map DNS servers supporting EDNS0 and ones not supporting it (i.e. which network operators should be bugged to support it...). it would be very good for network operators to see e.g. in-country adoption rate before relying on a CDN using EDNS0 as the core POP routing technology.
Mapping EDNS0 support can be done today. There are the various DNSSEC related flags and udp payload size. And probes can prepend their probe ids so you can see at the dns server which probe is which.
Unfortunately, this doesn't seem to work so well either: https://atlas.ripe.net/measurements/3115499/ Can anyone here help me figure out why almost all requests end up being null and only very few of them show up the resultant TXT record? Gil On Thu, Dec 24, 2015 at 11:44 AM, Gil Bahat <gil@magisto.com> wrote:
actually, It would be extremely useful for the DNS probe results to immediately and clearly reflect whether any response included EDNS0 bits or not, without this being a separate test. I am trying to debug some oddball CDN DNS assignments and this means trying to hunt down specific probes and tweaking specific lookups in order to get this... inconvenient to the point of almost unusable with that regards. something like this is a quick hack to achieve it: https://www.dns-oarc.net/oarc/services/replysizetest yet, it's much better to have it built-in.
Regards,
Gil Bahat, DevOps and Network Engineer, Magisto Ltd.
On Thu, Dec 10, 2015 at 2:54 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
On 2015/12/10 13:43 , Gil Bahat wrote:
what could be very interesting though, is to map DNS servers supporting EDNS0 and ones not supporting it (i.e. which network operators should be bugged to support it...). it would be very good for network operators to see e.g. in-country adoption rate before relying on a CDN using EDNS0 as the core POP routing technology.
Mapping EDNS0 support can be done today. There are the various DNSSEC related flags and udp payload size. And probes can prepend their probe ids so you can see at the dns server which probe is which.
On 24/12/15 10:59, Gil Bahat wrote: Dear Gil,
Unfortunately, this doesn't seem to work so well either: https://atlas.ripe.net/measurements/3115499/ Can anyone here help me figure out why almost all requests end up being null and only very few of them show up the resultant TXT record?
The OARC reply-size tester works by sending a recursive resolver a series of CNAME records to follow. If the resolver has no problems, then it follows the chain quickly, and gets a result. However, if there are path MTU issues, for example, these queries time out. In this case, a resolver will take a long time to come back with the result. The RIPE Atlas DNS measurements all time out after 5 seconds, and this isn't enough time to always get results from the reply-size tester. This is most likely the reason why most of your results are empty, with a "timeout" error. Regards, Anand
Thank you very much, makes perfect sense. Can we increase the timeout somehow or specify it as a tunable query parameter? I find the OARC tester highly useful in conjunction with RIPE ATLAS. On Dec 26, 2015 12:24 PM, "Anand Buddhdev" <anandb@ripe.net> wrote:
On 24/12/15 10:59, Gil Bahat wrote:
Dear Gil,
Unfortunately, this doesn't seem to work so well either: https://atlas.ripe.net/measurements/3115499/ Can anyone here help me figure out why almost all requests end up being null and only very few of them show up the resultant TXT record?
The OARC reply-size tester works by sending a recursive resolver a series of CNAME records to follow. If the resolver has no problems, then it follows the chain quickly, and gets a result. However, if there are path MTU issues, for example, these queries time out. In this case, a resolver will take a long time to come back with the result.
The RIPE Atlas DNS measurements all time out after 5 seconds, and this isn't enough time to always get results from the reply-size tester. This is most likely the reason why most of your results are empty, with a "timeout" error.
Regards, Anand
On Wed, Dec 09, 2015 at 02:53:42PM -0500, Jared Mauch <jared@puck.nether.net> wrote a message of 20 lines which said:
Perhaps a method to just set the RRType as integer would work in the interim?
+1 for me.
participants (11)
-
Anand Buddhdev -
Daniel Kahn Gillmor -
Gil Bahat -
Jared Mauch -
Micha Bailey -
Philip Homburg -
Randy Bush -
Robert Kisteleki -
Shumon Huque -
Stephane Bortzmeyer -
Willem Toorop