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.