Re: Supporting LOC RR's
On 13-May-22 12:21, Philip Prindeville wrote: That's interesting, and clever work to solve the problem of making APs into reliable location references. They are doing a more involved/automated version of what I suggested - using GPS (in their case built-in GPS, plus AP-AP communication) for APs to locate themselves. Once the AP knows where it is, the clients can find out where they are in physical (WGS84 coordinate) space using the APs as references. Note that it's an enterprise solution - definitely not for most homes - since it requires at least 4, and probably many more suitable APs. But LOC records don't have any role in what's described. They *could* be an output (e.g. an AP could use DNS UPDATE to install LOC records). But there's still no obviously useful consumer for the LOCs...so why bother? If you're in WiFi range of the AP, a client is better off getting precise information from its broadcast. If not, it's useless. And as previously noted, LOC for servers suffers from AnyCast, cache, and CDN uncertainty. LOC was proposed in simpler times. Actually, if the AP doesn't have GPS but does offer WiFi Certified Location Service, then it could use its own LOC record to provision itself... -Philip WiFi Certified Location service computes the *relative* location of 2 WiFi devices. https://www.wi-fi.org/discover-wi-fi/wi-fi-location To offer an absolute location (what LOC provides), at least one AP has to know where it is (and broadcast it). Then additional APs can compute their positions relative to it, and compute their absolute location(s). Either your AP knows where it is, or it finds out via WCL (or some other means: e.g. GPS or configuration). If you want an AP to find out where it is via LOC, someone has to generate the LOC record. And the AP needs to be able to find it - meaning it has been configured with an IP address and/or name. If you want to participate in WCL, you want the LOC to have a precise (and accurate) position. OTOH, if an AP is participating in WCL and doesn't know its absolute location, it can compute it using WCL if some other AP knows and broadcasts its own absolute location. This conversation has come full circle. Where does the LOC record's position data come from, and who (or what) provisions it? And (assuming the AP doesn't have GPS or another reference, such as installed WCL APs) why is that easier/better than putting the data in the AP's config? As I noted, *after* an AP knows where it is, it *could* generate a LOC record, and even install it. But that makes it an *output* of provisioning, not an input. And there's still no obvious customer. Yes, some other AP could then use the first AP's LOC with WCL to determine its absolute location. (Well, you probably need three APs to triangulate...) But it's less work all around to get it from the first AP's broadcast. And you still have the bootstrapping problem. WCL clients have no use for LOC. If you want to map your APs, you can ask them for their locations directly. Much as some would like it to be, involving DNS isn't the answer to everything. If you still want to convince yourself that LOC is useful: starting with an empty building, some unprovisioned APs, and no LOC records, provide an algorithm that provisions your AP(s). Specify all inputs and where they come from. Contrast it with the HP video and/or manual configuration. Show what steps your algorithm eliminates and/or facilitates, and at what cost. I don't expect a positive outcome, but if I'm wrong, by all means post the details. Since this has indeed come full circle, I'm done. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
> That's interesting, and clever work to solve the problem of making APs into > reliable location references. > > They are doing a more involved/automated version of what I suggested - using > GPS (in their case built-in GPS, plus AP-AP communication) for APs to locate > themselves. Once the AP knows where it is, the clients can find out where > they are in physical (WGS84 coordinate) space using the APs as references. > Note that it's an enterprise solution - definitely not for most homes - since > it requires at least 4, and probably many more suitable APs. > > But LOC records don't have any role in what's described. They *could* be an > output (e.g. an AP could use DNS UPDATE to install LOC records). But there's > still no obviously useful consumer for the LOCs...so why bother? > > If you're in WiFi range of the AP, a client is better off getting precise > information from its broadcast. If not, it's useless. And as previously > noted, LOC for servers suffers from AnyCast, cache, and CDN uncertainty. > > LOC was proposed in simpler times. Actually, if the AP doesn't have GPS but does offer WiFi Certified Location Service, then it could use its own LOC record to provision itself... -Philip -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
> On 2022-05-02 18:01, Timothe Litt wrote: >> Still, overall DNS seems to generate more problems than fun, so if LOC >> provides amusement, it's a good thing. > > I know one of my users found them quite amusing. I can't recall what > location they picked or why, but it had some sort of personal > significance (and wasn't privacy invasive). > > I've always wondered if there was a real-world use case. Displaying traceroute results on an actual geographical map? But I guess that didn't ever really catch on. Regards, - Håvard -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
I have in the past considered that putting these kinds of records in for anycast nodes (such as, but not limited to root DNS servers), so that a person can glean how far they are from the node serving them (gleaned via hostname.bind or NSID), would be useful and fun science, in that in this way all the info you need would be “in the DNS”. The fun derivation of “shortest distance with highest latency” is a fun exercise for the audience. -Dan > On May 3, 2022, at 3:07 AM, Tony Finch wrote: > > Timothe Litt wrote: >> On 02-May-22 09:02, Stephane Bortzmeyer wrote: > >>> Fun is a sufficient reason. >> >> I would never discourage anyone from having (harmless) fun. >> >> On the other hand, unless your codes postaux are spherical (or a circular >> projection), your LOC will be at best an approximation of a point in the >> postal zone. > > At my previous job there used to be a TXT record at cam.ac.uk saying > "The University of Cambridge", which I replaced with a LOC record to avoid > interference with things like SPF and domain authentication. It's also > used as a test record by the keepalived health check scripts. > > Cambridge has a residency rule for students that requires them to live > within 3 miles of the city centre, so the 10km diameter in the LOC record > is in some sense correct and reasonably accurate. > > cam.ac.uk LOC 52 12 19.000 N 0 7 5.000 E 18.00m 1m 100m 100m > > -- > Tony Finch(he/they) Cambridge, England > Lundy, Fastnet, Irish Sea: Variable becoming southwest, 2 to 4. Smooth > or slight. Occasional rain or drizzle, fog patches in Irish Sea. > Moderate or good, occasionally very poor in Irish Sea. > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On 2022-05-02 18:01, Timothe Litt wrote: Still, overall DNS seems to generate more problems than fun, so if LOC provides amusement, it's a good thing. I know one of my users found them quite amusing. I can't recall what location they picked or why, but it had some sort of personal significance (and wasn't privacy invasive). I've always wondered if there was a real-world use case. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
Timothe Litt wrote: > On 02-May-22 09:02, Stephane Bortzmeyer wrote: > > Fun is a sufficient reason. > > I would never discourage anyone from having (harmless) fun. > > On the other hand, unless your codes postaux are spherical (or a circular > projection), your LOC will be at best an approximation of a point in the > postal zone. At my previous job there used to be a TXT record at cam.ac.uk saying "The University of Cambridge", which I replaced with a LOC record to avoid interference with things like SPF and domain authentication. It's also used as a test record by the keepalived health check scripts. Cambridge has a residency rule for students that requires them to live within 3 miles of the city centre, so the 10km diameter in the LOC record is in some sense correct and reasonably accurate. cam.ac.uk LOC 52 12 19.000 N 0 7 5.000 E 18.00m 1m 100m 100m -- Tony Finch(he/they) Cambridge, England Lundy, Fastnet, Irish Sea: Variable becoming southwest, 2 to 4. Smooth or slight. Occasional rain or drizzle, fog patches in Irish Sea. Moderate or good, occasionally very poor in Irish Sea. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On 02-May-22 09:02, Stephane Bortzmeyer wrote: On Wed, Apr 13, 2022 at 03:39:33PM +0200, Bjørn Mork wrote a message of 14 lines which said: Which problems do LOC solve? I remember adding LOC records for fun?() in the previous millennium when RFC 1876 was fresh out of the press. But even back then paranoia finally took over, and I deleted all of them. Don't think I ever found anything to actually use them for. Fun is a sufficient reason. French zip codes to LOC: % dig +short +nodnssec LOC 34000.cp.bortzmeyer.fr 43 36 47.108 N 3 52 9.113 E 0.00m 1m 1m 10m https://www.bortzmeyer.org/dns-code-postal-lonlat.html (in French) I would never discourage anyone from having (harmless) fun. On the other hand, unless your codes postaux are spherical (or a circular projection), your LOC will be at best an approximation of a point in the postal zone. Perhaps the post office, or the geographic center, or a public building, or a monument, or the best restaurant, or...? LOC can't represent the boundaries of most (any?) postal zones, as they tend to be polygons (or with curves, simply a closed path). So the most fun may be guessing the meaning of the result :-) Still, overall DNS seems to generate more problems than fun, so if LOC provides amusement, it's a good thing. Malheureusement, LOC's practical application remains unclear. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
Fun is a sufficient reason. Definitely. IATA airport codes to LOC: % dig +short CDG.air.jpmens.net LOC 49 0 46.073 N 2 33 0.000 E 119.00m 1m 1m 10m and more fun with an associated TXT: % dig +short CDG.air.jpmens.net TXT "cc:FR; m:Paris; t:large, n:Charles de Gaulle International Airport" with more at https://jpmens.net/2020/10/04/airports-of-the-world/ -JP -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On Wed, Apr 13, 2022 at 03:39:33PM +0200, Bjørn Mork wrote a message of 14 lines which said: > Which problems do LOC solve? > > I remember adding LOC records for fun?() in the previous millennium when > RFC 1876 was fresh out of the press. But even back then paranoia > finally took over, and I deleted all of them. > > Don't think I ever found anything to actually use them for. Fun is a sufficient reason. French zip codes to LOC: % dig +short +nodnssec LOC 34000.cp.bortzmeyer.fr 43 36 47.108 N 3 52 9.113 E 0.00m 1m 1m 10m https://www.bortzmeyer.org/dns-code-postal-lonlat.html (in French) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On 01-May-22 05:03, Bob Harold wrote: On Wed, Apr 13, 2022 at 9:39 AM Bjørn Mork wrote: Timothe Litt writes: > Anyhow, it's not clear exactly what problem you're asking LOC (or > anything) to solve. Which problems do LOC solve? I remember adding LOC records for fun?() in the previous millennium when RFC 1876 was fresh out of the press. But even back then paranoia finally took over, and I deleted all of them. Don't think I ever found anything to actually use them for. Bjørn -- WIth regard to locating access points: Self-locating wifi APs https://www.youtube.com/watch?v=kVdFNR0R3EE That's interesting, and clever work to solve the problem of making APs into reliable location references. They are doing a more involved/automated version of what I suggested - using GPS (in their case built-in GPS, plus AP-AP communication) for APs to locate themselves. Once the AP knows where it is, the clients can find out where they are in physical (WGS84 coordinate) space using the APs as references. Note that it's an enterprise solution - definitely not for most homes - since it requires at least 4, and probably many more suitable APs. But LOC records don't have any role in what's described. They *could* be an output (e.g. an AP could use DNS UPDATE to install LOC records). But there's still no obviously useful consumer for the LOCs...so why bother? If you're in WiFi range of the AP, a client is better off getting precise information from its broadcast. If not, it's useless. And as previously noted, LOC for servers suffers from AnyCast, cache, and CDN uncertainty. LOC was proposed in simpler times. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On Wed, Apr 13, 2022 at 9:39 AM Bjørn Mork wrote: > Timothe Litt writes: > > > Anyhow, it's not clear exactly what problem you're asking LOC (or > > anything) to solve. > > Which problems do LOC solve? > > I remember adding LOC records for fun?() in the previous millennium when > RFC 1876 was fresh out of the press. But even back then paranoia > finally took over, and I deleted all of them. > > Don't think I ever found anything to actually use them for. > > > Bjørn > -- > > WIth regard to locating access points: Self-locating wifi APs https://www.youtube.com/watch?v=kVdFNR0R3EE -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
Timothe Litt writes: > Anyhow, it's not clear exactly what problem you're asking LOC (or > anything) to solve. Which problems do LOC solve? I remember adding LOC records for fun?() in the previous millennium when RFC 1876 was fresh out of the press. But even back then paranoia finally took over, and I deleted all of them. Don't think I ever found anything to actually use them for. Bjørn -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On 12-Apr-22 14:15, Philip Prindeville wrote: In my case, I do split-horizon for my domain in-house and use RFC-1918 addresses, so leaking them with the internet would be pointless anyway. I have separate LOC records for in-house and external views. The in-house version is high precision. The external version is fuzzed. I use LOC records on domains; the comparison with IP geolocation is because the usual alternative to LOC is to translate the domain name to an IP address; then geolocate that using one of the commercial databases. Of course, that gets tricky when a hostname has multiple IP addresses or is served by anycast (such as a CDN). In that case, the semantics aren't obvious - should the location be that of the CDN server (and which one)? The origin server? And with 1918/NAT, the origin server may be in different locations depending on the protocol used. (E.g. one public IP address, with an SMTP server in one building and a WWW server in another) With WPs, you're not trying to locate a host at all; you're trying to infer (or calculate) the mobile device client's location. Or assist the mobile device to calculate its location. It's not clear to me that it's less work to prepopulate LOC records than to put a cellphone on top of the WAP before turning it on, getting the GPS coordinates (e.g. see the 'gpstest' app), and pasting them into the WAP's configuration. If you really want cm scale accuracy, you need some kind of surveying instrument - whose data has to go someplace - be it LOC or the WAP configuration. Or the new AP figures out its location based on triangulating from existing APs that somehow are deemed trustworthy. THEY might have LOC records to help, but that's not pre-provisioning. Maybe the new AP could then publish a LOC record with its location to help clients. But I don't see how pre-provisioning helps setting up a new AP in this case; you might do the survey before the WAP arrives, but once the survey instrument reports a position, you either have prepared a configuration file for it (usual case), or you have to find it & configure it at that point. Either way, setting the location is the smallest part of setting up a configuration - VLANs, SSIDs, access control/portals take much more work. Anyhow, it's not clear exactly what problem you're asking LOC (or anything) to solve. BTW, RFC1876 is worth reading for the suggested search algorithms. I don't think it ever moved from "experimental", which may be part of why uptake hasn't been great. Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
> On Apr 12, 2022, at 6:36 AM, Timothe Litt wrote: > > > On 12-Apr-22 01:46, Philip Prindeville wrote: >> Does anyone use LOC RR's? And if so, how? >> >> I've had some Apple devices get seriously confused by their location >> services and I'm trying to provide strong hints. >> >> It would also be nice to prime WiFi 6 Certified WAPs with their locations >> based on LOC RR's since we happen to have convenient infrastructure to do >> exactly that. >> >> Thanks. >> >> > LOC RR's are not currently very popular. But I have some where they provide > different locations from geolocation services based on IP address. Google, > for one, reports the city from the LOC record in preference to data > associated with the IP address. I haven't looked recently, but last time I > looked, the geolocation services' use of LOC was spotty. Some used LOC, > other's didn't. For them, it's pretty cheap to mine WHOIS and address block > assignments; doing a DNS lookup for each address (and walking up the tree on > a miss) gets expensive fairly fast. > > There are some concerns with overly precise LOC records - great if you want a > shopper to to show up at your store, perhaps less so if you run a shelter or > secure facility. I've been known to intentionally misplace LOC records so > that they're good enough for routing, census, and other coarse applications, > but not accurate enough for navigation. > > With respect to part 2: You might also consider that GPS receivers are cheap > (every cellphone has one) and retail USB receivers are easily found at less > than $20. This may be a better choice than LOC records. GPS tells you where > you are; LOC tells everyone else... > > HTH > > Timothe Litt > ACM Distinguished Engineer > -- > This communication may not represent the ACM or my employer's views, > if any, on the matters discussed. > That's where things get interesting with WiFi 6 Certified Location: it's potentially accurate to a few centimeters if it's done correctly. I have Ubiquiti UAP-AC-Pro's which don't support this feature, but could if Ubiquiti bothered to add the functionality (it's not on their roadmap as far as I can tell). In my case, I do split-horizon for my domain in-house and use RFC-1918 addresses, so leaking them with the internet would be pointless anyway. I'm doing the LOC record matching the domain for now. I could have LOC records for the WAP's to pre-provision them, but like I said, Ubiquiti isn't caught up yet. -Philip -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Supporting LOC RR's
On 12-Apr-22 01:46, Philip Prindeville wrote: Does anyone use LOC RR's? And if so, how? I've had some Apple devices get seriously confused by their location services and I'm trying to provide strong hints. It would also be nice to prime WiFi 6 Certified WAPs with their locations based on LOC RR's since we happen to have convenient infrastructure to do exactly that. Thanks. LOC RR's are not currently very popular. But I have some where they provide different locations from geolocation services based on IP address. Google, for one, reports the city from the LOC record in preference to data associated with the IP address. I haven't looked recently, but last time I looked, the geolocation services' use of LOC was spotty. Some used LOC, other's didn't. For them, it's pretty cheap to mine WHOIS and address block assignments; doing a DNS lookup for each address (and walking up the tree on a miss) gets expensive fairly fast. There are some concerns with overly precise LOC records - great if you want a shopper to to show up at your store, perhaps less so if you run a shelter or secure facility. I've been known to intentionally misplace LOC records so that they're good enough for routing, census, and other coarse applications, but not accurate enough for navigation. With respect to part 2: You might also consider that GPS receivers are cheap (every cellphone has one) and retail USB receivers are easily found at less than $20. This may be a better choice than LOC records. GPS tells you where you are; LOC tells everyone else... HTH Timothe Litt ACM Distinguished Engineer -- This communication may not represent the ACM or my employer's views, if any, on the matters discussed. OpenPGP_signature Description: OpenPGP digital signature -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Supporting LOC RR's
Does anyone use LOC RR's? And if so, how? I've had some Apple devices get seriously confused by their location services and I'm trying to provide strong hints. It would also be nice to prime WiFi 6 Certified WAPs with their locations based on LOC RR's since we happen to have convenient infrastructure to do exactly that. Thanks. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
