LOC
Last updated
Last updated
The parameter number types ingested are as follows:
Strictly follows .
A LOC record holds a geographical position. In the zone file, it may look like:
On the wire, it is in a binary format.
A use case for LOC is suggested in the RFC:
Some uses for the LOC RR have already been suggested, including the USENET backbone flow maps, a "visual traceroute" application showing the geographical path of an IP packet, and network management applications that could use LOC RRs to generate a map of hosts and routers being managed.
There are some behaviours that you should be aware of, however:
If omitted, minutes and seconds default to zero, size defaults to 1m, horizontal precision defaults to 10000m, and vertical precision defaults to 10m. These defaults are chosen to represent typical ZIP/postal code area sizes, since it is often easy to find approximate geographical location by ZIP/postal code.
Alas, the world does not revolve around US ZIP codes, but here we are. Internally, the LOC record type will supply defaults where values were absent on DNS import. One must supply the LOC()
js helper all parameters. If that seems like too much work, see also helper functions:
The coordinate format for LOC()
is:
degrees,minutes,seconds,[NnSs],deg,min,sec,[EeWw],altitude,size,horizontal_precision,vertical_precision
where: altitude: [-100000.00 .. 42849672.95] BY .01 (altitude in meters) size, horizontal_precision, vertical_precision: [0 .. 90000000.00] (size/precision in meters)
values outside of the above ranges are gated to within the ranges.
There is the UK based whereby you can do:
- build a LOC
by supplying only decimal degrees.
- accepts DMS 33°51′31″S 151°12′51″E
- accepts DMM 25.24°S 153.15°E
- tries the coordinate string in all LOC_BUILDER_DM*_STR()
functions until one works