[atlas]DNS records for the probes' internet address
Hi list, I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else. I would think such a feature would be a small incentive for home broadband users to become probe hosts. On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
On 02/12/2010 11:17, Tore Anderson wrote:
Hi list,
I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else.
We can see if there is broader interest for this feature and make it an opt-in (checkbox in the GUI). One thing to be careful about here is that having all probes in easy to guess hostnames, will make it easy to DoS part of the infrastructure. Doing it as an opt-in, will make sure that only the people that want/need this feature will enable it, and if that is a sufficiently low fraction of total, it makes it unlikely as a DoS target.
I would think such a feature would be a small incentive for home broadband users to become probe hosts.
On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up.
As we speak, probes are upgrading to firmware version 3900, which solves this problem (see http://atlas.ripe.net/dynamic/stats/stats.probe_versions.png for overall status). In case people still see this problem by the end of the day with firmware version < 3900 and want to force firmware version 3900 onto their probes: You can force the upgrade by rebooting (unplugging and replugging) your probe. Emile
* Emile Aben
We can see if there is broader interest for this feature and make it an opt-in (checkbox in the GUI). One thing to be careful about here is that having all probes in easy to guess hostnames, will make it easy to DoS part of the infrastructure. Doing it as an opt-in, will make sure that only the people that want/need this feature will enable it, and if that is a sufficiently low fraction of total, it makes it unlikely as a DoS target.
You could also of course make the hostname harder to guess, generating some random UID that's part of the FQDN and that each host have to look up in the Atlas dashboard manually, and set up easier-to-remember CNAMEs perhaps. By the way - when it comes to secrecy for privacy reasons, I'd personally very much like to make my probes as public as possible (doesn't necessarily have to include listing the IP address if you're concerned about DoS attacks). Because one way I can imagine the Atlas projects being immensely useful to network operators world-wide is if it can be used as a kind of massive public looking glass. Someone could then go to the dashboard and query for a listing of probes dependent on various parameters, such as in autonomous system #N or in country/city/continent Foo, select the probes he wants, and then request an arbitrary traceroute or ping to be run from those probes. Heck, I'd even give it a BGP feed people could query like that too, but I assume it doesn't have the horsepower to deal with that... I know I would certainly allow the probes I host to be used like that and hope that as many others as possible did so too. I have no idea of how of I have tried to debug a connectivity problem from some random source network and have unsuccessfully searched for a looking glass that could help me with it, but it's _a lot_ of times. I'm sure I'm not alone about that, and if people see that Atlas provides such an awesomely useful service I'm sure that would in turn make them more interested in participating by hosting or sponsoring probes of their own.
You can force the upgrade by rebooting (unplugging and replugging) your probe.
HA! Trying to cheat me out of my iPad, are you? That's low, Emile, low...your diabolical tricks won't work on me! =D Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
Hi, On 2010.12.02. 12:41, Tore Anderson wrote:
* Emile Aben
We can see if there is broader interest for this feature and make it an opt-in (checkbox in the GUI). One thing to be careful about here is that having all probes in easy to guess hostnames, will make it easy to DoS part of the infrastructure. Doing it as an opt-in, will make sure that only the people that want/need this feature will enable it, and if that is a sufficiently low fraction of total, it makes it unlikely as a DoS target.
You could also of course make the hostname harder to guess, generating some random UID that's part of the FQDN and that each host have to look up in the Atlas dashboard manually, and set up easier-to-remember CNAMEs perhaps.
We could do that too. Or make it an option for the users, like "probe DNS registration: none, obfuscated, simple".
By the way - when it comes to secrecy for privacy reasons, I'd personally very much like to make my probes as public as possible (doesn't necessarily have to include listing the IP address if you're concerned about DoS attacks). Because one way I can imagine the Atlas projects being immensely useful to network operators world-wide is if it can be used as a kind of massive public looking glass. Someone could then go to the dashboard and query for a listing of probes dependent on various parameters, such as in autonomous system #N or in country/city/continent Foo, select the probes he wants, and then request an arbitrary traceroute or ping to be run from those probes. Heck, I'd even give it a BGP feed people could query like that too, but I assume it doesn't have the horsepower to deal with that...
Some of these are in our mid-term plans already. For example: * We will allow hosts to make some or all their measurement activities and results public. We have a couple of probes in our office, and I don't think we mind opening their measurements up to the public. (Home users might not want to do this.) * (Ssssh, don't tell anyone yet, but...) we started collecting IPv4/6 prefixes and ASNs of hosts. We plan to make this available, probably even searchable ("how many probes do you have in AS x?"). It'd be nice if one could refine this with the above, as "... and how many made their measurements available?" * At a later stage, once you can specify your own measurements, we want to allow you to say "use these sources for my measurement", so you could do on-demand stuff to/from anywhere to some extent. I think we're pretty much aligned on these features, and I'm confident we can deal with the privacy implications, if any.
I know I would certainly allow the probes I host to be used like that and hope that as many others as possible did so too. I have no idea of how of I have tried to debug a connectivity problem from some random source network and have unsuccessfully searched for a looking glass that could help me with it, but it's _a lot_ of times. I'm sure I'm not alone about that, and if people see that Atlas provides such an awesomely useful service I'm sure that would in turn make them more interested in participating by hosting or sponsoring probes of their own.
Exactly. We're building something with great potential, so this kind of feedback is very much welcome! Cheers, Robert
Hello, On 02.12.2010, at 12:59, Robert Kisteleki wrote:
Some of these are in our mid-term plans already. For example: * We will allow hosts to make some or all their measurement activities and results public. We have a couple of probes in our office, and I don't think we mind opening their measurements up to the public. (Home users might not want to do this.)
in addition to that (as an option for home users) an "ACL" option would be nice ("I allow you to see my probe, please allow me to see yours") best regards, Wolfgang --- Wolfgang Tremmel, WT5-RIPE tremmel@garf.de
Hi Tore, yes, manufacturing a DNS name for my/our probe/s was one of the first actions during installation :-) Tore Anderson wrote:
Hi list,
I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should.
What would be your suggested mechanism to keep this in synch with the DNS zone data?
I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else.
I would think such a feature would be a small incentive for home broadband users to become probe hosts.
On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up.
Best regards,
Cheers, Wilfried
On 2 Dec 2010, at 15:10, Wilfried Woeber, UniVie/ACOnet wrote:
Hi Tore,
yes, manufacturing a DNS name for my/our probe/s was one of the first actions during installation :-)
Tore Anderson wrote:
Hi list,
I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should.
What would be your suggested mechanism to keep this in synch with the DNS zone data?
dynamic updates, I guess. If the probe can't handle that in its firmware then the receiving side, at the NCC, could update a local zone (what Tore was suggesting). This is a request for a service like what dyndns and others do, which has support in quite a few DSL routers these days, but without having to subscribe to these services.
I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else.
I would think such a feature would be a small incentive for home broadband users to become probe hosts.
On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up.
Best regards,
Cheers, Wilfried
talking as an individual. Isn't it the same as probe ID? just another namespace. I wonder how forward dns would scale for large sensor networks. I have my doubts on usability and maintaining operational constancy of forward dns records when probes change ip addresses. For example, German DSL networks might change probe's public IP-address every day. May be as Jo?o suggested dyndns could work in theory. Once there are 1000s of probes what good are forward names. Then we will need hierarchies. one hierarchuy based on geography, one based network prefixes, asns .. Currently these probes just send out measurements and don't respond to anything but ping. On the other hand if the probes become more static say something like an rpsl-reachable-test [1] there is definitely value for forward dns. Then you actually want a name to IP address mapping. regards, -antony [1] http://tools.ietf.org/html/draft-haberman-rpsl-reachable-test-04 On Thu, Dec 02, 2010 at 11:17:13AM +0100, Tore Anderson wrote:
Hi list,
I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else.
I would think such a feature would be a small incentive for home broadband users to become probe hosts.
On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
Antony, the "good" is for the users. It would provide them with a stable name to address the variable external IP they get from the ISP, enabling access to home machines from the outside using the name, independently of what IP the DSL modem/cable modem happens to have at any given time Joao On 2 Dec 2010, at 17:27, Antony Antony wrote:
talking as an individual.
Isn't it the same as probe ID? just another namespace. I wonder how forward dns would scale for large sensor networks.
I have my doubts on usability and maintaining operational constancy of forward dns records when probes change ip addresses. For example, German DSL networks might change probe's public IP-address every day. May be as Jo?o suggested dyndns could work in theory. Once there are 1000s of probes what good are forward names. Then we will need hierarchies. one hierarchuy based on geography, one based network prefixes, asns ..
Currently these probes just send out measurements and don't respond to anything but ping.
On the other hand if the probes become more static say something like an rpsl-reachable-test [1] there is definitely value for forward dns. Then you actually want a name to IP address mapping.
regards, -antony
[1] http://tools.ietf.org/html/draft-haberman-rpsl-reachable-test-04
On Thu, Dec 02, 2010 at 11:17:13AM +0100, Tore Anderson wrote:
Hi list,
I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else.
I would think such a feature would be a small incentive for home broadband users to become probe hosts.
On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
João Damas wrote:
Antony, the "good" is for the users. It would provide them with a stable name to address the variable external IP they get from the ISP, enabling access to home machines from the outside using the name, independently of what IP the DSL modem/cable modem happens to have at any given time
Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I doubt that it is a reasonable investment to teach the small things to do dynamic DNS *centrally*. To be able to get a grip on that one, I think we'd need to better understand when and how the probe detects an change of address? My feeling is that tracking of IP to name mapping is a local issue. Wilfried
Joao
On 2 Dec 2010, at 17:27, Antony Antony wrote:
talking as an individual.
Isn't it the same as probe ID? just another namespace. I wonder how forward dns would scale for large sensor networks.
I have my doubts on usability and maintaining operational constancy of forward dns records when probes change ip addresses. For example, German DSL networks might change probe's public IP-address every day. May be as Jo?o suggested dyndns could work in theory. Once there are 1000s of probes what good are forward names. Then we will need hierarchies. one hierarchuy based on geography, one based network prefixes, asns ..
Currently these probes just send out measurements and don't respond to anything but ping.
On the other hand if the probes become more static say something like an rpsl-reachable-test [1] there is definitely value for forward dns. Then you actually want a name to IP address mapping.
regards, -antony
[1] http://tools.ietf.org/html/draft-haberman-rpsl-reachable-test-04
On Thu, Dec 02, 2010 at 11:17:13AM +0100, Tore Anderson wrote:
Hi list,
I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else.
I would think such a feature would be a small incentive for home broadband users to become probe hosts.
On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
On 2 Dec 2010, at 21:30, Wilfried Woeber, UniVie/ACOnet wrote:
João Damas wrote:
Antony, the "good" is for the users. It would provide them with a stable name to address the variable external IP they get from the ISP, enabling access to home machines from the outside using the name, independently of what IP the DSL modem/cable modem happens to have at any given time
Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I doubt that it is a reasonable investment to teach the small things to do dynamic DNS *centrally*.
I think Tore's original proposal was that the probe do nothing special, rather the central servers at the NCC would be doing all the work (detecting the new IP and feeding it into the forward DNS zone). I use dyndns as an example of why this is useful, not as an example of a technical solution to be applied here (and in any case I am not the one working on the probes or the servers, so I have nothing to say about how it is done. I am just showing why it is useful and supporting the request) Joao
João, good point! I was barking at the wrong tree, by assuming a particular implementation ;-/ João Damas wrote:
On 2 Dec 2010, at 21:30, Wilfried Woeber, UniVie/ACOnet wrote:
João Damas wrote:
Antony, the "good" is for the users. It would provide them with a stable name to address the variable external IP they get from the ISP, enabling access to home machines from the outside using the name, independently of what IP the DSL modem/cable modem happens to have at any given time
Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I doubt that it is a reasonable investment to teach the small things to do dynamic DNS *centrally*.
I think Tore's original proposal was that the probe do nothing special, rather the central servers at the NCC would be doing all the work (detecting the new IP and feeding it into the forward DNS zone). I use dyndns as an example of why this is useful, not as an example of a technical solution to be applied here (and in any case I am not the one working on the probes or the servers, so I have nothing to say about how it is done. I am just showing why it is useful and supporting the request)
Joao
Wilfried. PS: thanks to the Team for shipping 3900 and showing the IPv6 address. Well done!
Good morning, * Wilfried Woeber, UniVie/ACOnet
Actually, I can see the beauty of name-to-dynamic-IP-tracking, but I doubt that it is a reasonable investment to teach the small things to do dynamic DNS *centrally*.
Clearly it would be a waste of the probe's constrained resources to make it do such DNS updates itself. I didn't mean to suggest that the probe should change in any way. The central Atlas system, *already* knows all the necessary information. If you check your probe details on the web page, you will see a field called «Internet Address», which will differ from «Local Address» if the probe is behind the NAT. So my idea was simply to set up a DNS server with a custom zone backend that looked up this information directly from the central database it's stored in. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
The central Atlas system, *already* knows all the necessary information. If you check your probe details on the web page, you will see a field called «Internet Address», which will differ from «Local Address» if the probe is behind the NAT. So my idea was simply to set up a DNS server with a custom zone backend that looked up this information directly from the central database it's stored in.
As you already concluded, we have the data to make this happen. It also seems that some of you probe hosts would find it useful -- but for completely different reasons, not for Atlas functionality as such. I have to admit this was not in our planning, but we're willing to listen to what you need :) So one thing we could do is to allow hosts to opt in to some form of probe DNS registration: simple or obfuscated. We could put this on our todo list if there's enough demand. Please let us know if you'd like to use such a feature. Regards, Robert
* Robert Kisteleki
As you already concluded, we have the data to make this happen. It also seems that some of you probe hosts would find it useful -- but for completely different reasons, not for Atlas functionality as such. I have to admit this was not in our planning, but we're willing to listen to what you need :)
So one thing we could do is to allow hosts to opt in to some form of probe DNS registration: simple or obfuscated. We could put this on our todo list if there's enough demand. Please let us know if you'd like to use such a feature.
As you can probably guess, I would. However, I don't feel it's a very important feature. If it requires diverting significant amounts of development resources away from more important features (such as implementing a massive public looking glass functionality, hint hint ;-) - don't bother! But if can be implemented quickly with little effort, it would be cool feature adding value to volunteering as a probe host. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
+1 On 3 Dec 2010, at 11:05, Tore Anderson wrote:
* Robert Kisteleki
As you already concluded, we have the data to make this happen. It also seems that some of you probe hosts would find it useful -- but for completely different reasons, not for Atlas functionality as such. I have to admit this was not in our planning, but we're willing to listen to what you need :)
So one thing we could do is to allow hosts to opt in to some form of probe DNS registration: simple or obfuscated. We could put this on our todo list if there's enough demand. Please let us know if you'd like to use such a feature.
As you can probably guess, I would.
However, I don't feel it's a very important feature. If it requires diverting significant amounts of development resources away from more important features (such as implementing a massive public looking glass functionality, hint hint ;-) - don't bother!
But if can be implemented quickly with little effort, it would be cool feature adding value to volunteering as a probe host.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
+100 ;-) On 03.12 11:07, Jo?o Damas wrote:
+1
On 3 Dec 2010, at 11:05, Tore Anderson wrote:
* Robert Kisteleki
As you already concluded, we have the data to make this happen. It also seems that some of you probe hosts would find it useful -- but for completely different reasons, not for Atlas functionality as such. I have to admit this was not in our planning, but we're willing to listen to what you need :)
So one thing we could do is to allow hosts to opt in to some form of probe DNS registration: simple or obfuscated. We could put this on our todo list if there's enough demand. Please let us know if you'd like to use such a feature.
As you can probably guess, I would.
However, I don't feel it's a very important feature. If it requires diverting significant amounts of development resources away from more important features (such as implementing a massive public looking glass functionality, hint hint ;-) - don't bother!
But if can be implemented quickly with little effort, it would be cool feature adding value to volunteering as a probe host.
Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27
participants (8)
-
Antony Antony -
Daniel Karrenberg -
Emile Aben -
João Damas -
Robert Kisteleki -
Tore Anderson -
Wilfried Woeber, UniVie/ACOnet -
Wolfgang Tremmel