New on RIPE Labs: Researching F-root Anycast Placement Using RIPE Atlas
Dear colleagues, Please find a new article on RIPE Labs: https://labs.ripe.net/Members/ray_bellis/researching-f-root-anycast-placemen... In order to expand the reach of F-root, Ray Bellis looked at where queries to F-root are coming from and where it would make most sense to place new nodes. As a first step, Ray looked at the existing nodes to see how they behave and if there is anything that can be improved. He used RIPE Atlas to do this. Kind regards, Mirjam Kuehne RIPE NCC
from a discussion in montréal q: why do we anycast dns? a: for attack resistance, latency is a secondary effect q: what are the majority of queries? a: trash q: where should we place instances? a: near folk who need queries answered. bzzzt! no! a: near the sources of the rubbish so it can be absorbed quickly randy
q: where should we place instances? a: near folk who need queries answered. bzzzt! no! a: near the sources of the rubbish so it can be absorbed quickly
Perhaps it'd be useful to define the RQ (rubbish query) DNS flag? A'la rfc3514. Robert
Randy, On Wed, 14 Oct 2015 15:20:57 +0200 Randy Bush <randy@psg.com> wrote:
from a discussion in montréal
q: why do we anycast dns? a: for attack resistance, latency is a secondary effect
q: what are the majority of queries? a: trash
q: where should we place instances? a: near folk who need queries answered. bzzzt! no! a: near the sources of the rubbish so it can be absorbed quickly
Interesting point. This suggests a better (new?) metric is needed. I'm not exactly sure what this would be though. :) Cheers, -- Shane
q: where should we place instances? a: near folk who need queries answered. bzzzt! no! a: near the sources of the rubbish so it can be absorbed quickly
Interesting point. This suggests a better (new?) metric is needed. I'm not exactly sure what this would be though. :)
get out your triangulating crap-o-mometer
Awesome name for a new appliance: ACA Anycasted Crap Absorber ;) On 10/14/15 11:30 AM, Randy Bush wrote:
q: where should we place instances? a: near folk who need queries answered. bzzzt! no! a: near the sources of the rubbish so it can be absorbed quickly
Interesting point. This suggests a better (new?) metric is needed. I'm not exactly sure what this would be though. :)
get out your triangulating crap-o-mometer
On 14 Oct 2015, at 11:49, Carlos M. Martinez wrote:
Awesome name for a new appliance: ACA
Anycasted Crap Absorber
If we had some reasonable measure of crap, it might be interesting to see how well the sources and traffic correlates with what is received on AS112 nodes. I appreciate that this is a big ask for a loosely-coordinated, volunteer project. If there's a convincing correlation, then AS112 nodes would make good crap canaries that could guide the deployment of anycast instances for other DNS services. It'd also provide some commercial incentive for people to deploy AS112 nodes. Joe
Interesting idea. On 10/14/15 2:46 PM, Joe Abley wrote:
On 14 Oct 2015, at 11:49, Carlos M. Martinez wrote:
Awesome name for a new appliance: ACA
Anycasted Crap Absorber
If we had some reasonable measure of crap, it might be interesting to see how well the sources and traffic correlates with what is received on AS112 nodes. I appreciate that this is a big ask for a loosely-coordinated, volunteer project.
If there's a convincing correlation, then AS112 nodes would make good crap canaries that could guide the deployment of anycast instances for other DNS services. It'd also provide some commercial incentive for people to deploy AS112 nodes.
Joe
On 10/14/2015 01:46 PM, Joe Abley wrote:
On 14 Oct 2015, at 11:49, Carlos M. Martinez wrote:
Anycasted Crap Absorber
If we had some reasonable measure of crap, it might be interesting to see how well the sources and traffic correlates with what is received on AS112 nodes.
I had been having a similar thought - root crap does not necessarily == AS112 crap, but there's a pretty strong and clear crap signal arriving at AS112, and it ought to be at least possible to measure and infer any relation between the two as a first step.
I appreciate that this is a big ask for a loosely-coordinated, volunteer project.
As the loose co-ordinator of the AS112 project, OARC has been looking recently at ways of improving measurement of the aforementioned crap signal. If you are a large IXP or eyeball-ISP operator who would like to co-operate with OARC on operating and/or data-gathering AS112 nodes, we'd love to hear from you. Keith
Keith Mitchell <keith@dns-oarc.net> writes:
As the loose co-ordinator of the AS112 project, OARC has been looking recently at ways of improving measurement of the aforementioned crap signal. If you are a large IXP or eyeball-ISP operator who would like to co-operate with OARC on operating and/or data-gathering AS112 nodes, we'd love to hear from you.
Completely off topic, but this discussion made me look at the https://www.as112.net/ site again, only to be greeted by a terrifying(?) red icon by the TLSA validator plugin (https://www.dnssec-validator.cz/) Is it only me, or did someone forget to add a new TLSA record for _443._tcp.www.as112.net before changing the certificate? Yes, yes, I know, nobody are able to manage those records and the certificate is only a few hours old. But still :) Bjørn
On 10/14/2015 04:44 PM, Bjørn Mork wrote:
Completely off topic, but this discussion made me look at the https://www.as112.net/ site again, only to be greeted by a terrifying(?) red icon by the TLSA validator plugin (https://www.dnssec-validator.cz/)
Is it only me, or did someone forget to add a new TLSA record for _443._tcp.www.as112.net before changing the certificate?
Yes, yes, I know, nobody are able to manage those records and the certificate is only a few hours old. But still :)
Yeah, we renewed the certificate on time only to run into some subtle installation issues :-( I believe we've figured these now, it should be sorted very shortly. Keith
participants (8)
-
Bjørn Mork -
Carlos M. Martinez -
Joe Abley -
Keith Mitchell -
Mirjam Kuehne -
Randy Bush -
Robert Kisteleki -
Shane Kerr