File: rfc1876.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1011 lines) | stat: -rw-r--r-- 29,631 bytes parent folder | download | duplicates (12)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011






Network Working Group                                           C. Davis
Request for Comments: 1876                             Kapor Enterprises
Updates: 1034, 1035                                             P. Vixie
Category: Experimental                                 Vixie Enterprises
                                                              T. Goodwin
                                                            FORE Systems
                                                            I. Dickinson
                                                   University of Warwick
                                                            January 1996


 A Means for Expressing Location Information in the Domain Name System

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

1. Abstract

   This memo defines a new DNS RR type for experimental purposes.  This
   RFC describes a mechanism to allow the DNS to carry location
   information about hosts, networks, and subnets.  Such information for
   a small subset of hosts is currently contained in the flat-file UUCP
   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
   carry host and network address information, it is possible to replace
   the UUCP maps as carriers of location information.

   This RFC defines the format of a new Resource Record (RR) for the
   Domain Name System (DNS), and reserves a corresponding DNS type
   mnemonic (LOC) and numerical code (29).

   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
   RFC 1035].  The data shown in our examples is for pedagogical use and
   does not necessarily reflect the real Internet.














Davis, et al                  Experimental                      [Page 1]

RFC 1876            Location Information in the DNS         January 1996


2. RDATA Format

       MSB                                           LSB
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      0|        VERSION        |         SIZE          |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      2|       HORIZ PRE       |       VERT PRE        |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      4|                   LATITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      6|                   LATITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      8|                   LONGITUDE                   |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     10|                   LONGITUDE                   |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     12|                   ALTITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
     14|                   ALTITUDE                    |
       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
   (octet)

where:

VERSION      Version number of the representation.  This must be zero.
             Implementations are required to check this field and make
             no assumptions about the format of unrecognized versions.

SIZE         The diameter of a sphere enclosing the described entity, in
             centimeters, expressed as a pair of four-bit unsigned
             integers, each ranging from zero to nine, with the most
             significant four bits representing the base and the second
             number representing the power of ten by which to multiply
             the base.  This allows sizes from 0e0 (<1cm) to 9e9
             (90,000km) to be expressed.  This representation was chosen
             such that the hexadecimal representation can be read by
             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
             undefined, as are values with a base of zero and a non-zero
             exponent.

             Since 20000000m (represented by the value 0x29) is greater
             than the equatorial diameter of the WGS 84 ellipsoid
             (12756274m), it is therefore suitable for use as a
             "worldwide" size.

HORIZ PRE    The horizontal precision of the data, in centimeters,
             expressed using the same representation as SIZE.  This is
             the diameter of the horizontal "circle of error", rather



Davis, et al                  Experimental                      [Page 2]

RFC 1876            Location Information in the DNS         January 1996


             than a "plus or minus" value.  (This was chosen to match
             the interpretation of SIZE; to get a "plus or minus" value,
             divide by 2.)

VERT PRE     The vertical precision of the data, in centimeters,
             expressed using the sane representation as for SIZE.  This
             is the total potential vertical error, rather than a "plus
             or minus" value.  (This was chosen to match the
             interpretation of SIZE; to get a "plus or minus" value,
             divide by 2.)  Note that if altitude above or below sea
             level is used as an approximation for altitude relative to
             the [WGS 84] ellipsoid, the precision value should be
             adjusted.

LATITUDE     The latitude of the center of the sphere described by the
             SIZE field, expressed as a 32-bit integer, most significant
             octet first (network standard byte order), in thousandths
             of a second of arc.  2^31 represents the equator; numbers
             above that are north latitude.

LONGITUDE    The longitude of the center of the sphere described by the
             SIZE field, expressed as a 32-bit integer, most significant
             octet first (network standard byte order), in thousandths
             of a second of arc, rounded away from the prime meridian.
             2^31 represents the prime meridian; numbers above that are
             east longitude.

ALTITUDE     The altitude of the center of the sphere described by the
             SIZE field, expressed as a 32-bit integer, most significant
             octet first (network standard byte order), in centimeters,
             from a base of 100,000m below the [WGS 84] reference
             spheroid used by GPS (semimajor axis a=6378137.0,
             reciprocal flattening rf=298.257223563).  Altitude above
             (or below) sea level may be used as an approximation of
             altitude relative to the the [WGS 84] spheroid, though due
             to the Earth's surface not being a perfect spheroid, there
             will be differences.  (For example, the geoid (which sea
             level approximates) for the continental US ranges from 10
             meters to 50 meters below the [WGS 84] spheroid.
             Adjustments to ALTITUDE and/or VERT PRE will be necessary
             in most cases.  The Defense Mapping Agency publishes geoid
             height values relative to the [WGS 84] ellipsoid.









Davis, et al                  Experimental                      [Page 3]

RFC 1876            Location Information in the DNS         January 1996


3. Master File Format

   The LOC record is expressed in a master file in the following format:

   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
                               [vp["m"]]]] )

   (The parentheses are used for multi-line data as specified in [RFC
   1035] section 5.1.)

   where:

       d1:     [0 .. 90]            (degrees latitude)
       d2:     [0 .. 180]           (degrees longitude)
       m1, m2: [0 .. 59]            (minutes latitude/longitude)
       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)

   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.

4. Example Data

;;;
;;; note that these data would not all appear in one zone file
;;;

;; network LOC RR derived from ZIP data.  note use of precision defaults
cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m

;; higher-precision host LOC RR.  note use of vertical precision default
loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
                                    -24m 1m 200m

pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m

curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m

rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
                                    -44m 2000m






Davis, et al                  Experimental                      [Page 4]

RFC 1876            Location Information in the DNS         January 1996


5. Application use of the LOC RR

5.1 Suggested Uses

   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.

5.2 Search Algorithms

   This section specifies how to use the DNS to translate domain names
   and/or IP addresses into location information.

   If an application wishes to have a "fallback" behavior, displaying a
   less precise or larger area when a host does not have an associated
   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
   behaviour is the RECOMMENDED default, but in some cases it may need
   to be modified based on the specific requirements of the application
   involved.

   This search algorithm is designed to allow network administrators to
   specify the location of a network or subnet without requiring LOC RR
   data for each individual host.  For example, a computer lab with 24
   workstations, all of which are on the same subnet and in basically
   the same location, would only need a LOC RR for the subnet.
   (However, if the file server's location has been more precisely
   measured, a separate LOC RR for it can be placed in the DNS.)

5.2.1 Searching by Name

   If the application is beginning with a name, rather than an IP
   address (as the USENET backbone flow maps do), it MUST check for a
   LOC RR associated with that name.  (CNAME records should be followed
   as for any other RR type.)

   If there is no LOC RR for that name, all A records (if any)
   associated with the name MAY be checked for network (or subnet) LOC
   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
   multiple A records exist and have associated network or subnet LOC
   RRs, the application may choose to use any, some, or all of the LOC
   RRs found, possibly in combination.  It is suggested that multi-homed
   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
   in these cases.





Davis, et al                  Experimental                      [Page 5]

RFC 1876            Location Information in the DNS         January 1996


   Note that domain names that do not have associated A records must
   have a LOC RR associated with their name in order for location
   information to be accessible.

5.2.2 Searching by Address

   If the application is beginning with an IP address (as a "visual
   traceroute" application might be) it MUST first map the address to a
   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
   5.2.1), then check for a LOC RR associated with that name.

   If there is no LOC RR for the name, the address MAY be checked for
   network (or subnet) LOC RRs using the "Searching by Network or
   Subnet" algorithm (5.2.3).

5.2.3 Searching by Network or Subnet

   Even if a host's name does not have any associated LOC RRs, the
   network(s) or subnet(s) it is on may.  If the application wishes to
   search for such less specific data, the following algorithm SHOULD be
   followed to find a network or subnet LOC RR associated with the IP
   address.  This algorithm is adapted slightly from that specified in
   [RFC 1101], sections 4.3 and 4.4.

   Since subnet LOC RRs are (if present) more specific than network LOC
   RRs, it is best to use them if available.  In order to do so, we
   build a stack of network and subnet names found while performing the
   [RFC 1101] search, then work our way down the stack until a LOC RR is
   found.

   1. create a host-zero address using the network portion of the IP
      address (one, two, or three bytes for class A, B, or C networks,
      respectively).  For example, for the host 128.9.2.17, on the class
      B network 128.9, this would result in the address "128.9.0.0".

   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
      records.  Retrieve:

               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
                                        A      255.255.255.0

      Push the name "isi-net.isi.edu" onto the stack of names to be
      searched for LOC RRs later.








Davis, et al                  Experimental                      [Page 6]

RFC 1876            Location Information in the DNS         January 1996


   3. Since an A RR was found, repeat using mask from RR
      (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
      Retrieve:

               0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
                                        A      255.255.255.240

      Push the name "div2-subnet.isi.edu" onto the stack of names to be
      searched for LOC RRs later.

   4. Since another A RR was found, repeat using mask 255.255.255.240
      (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
      Retrieve:

               16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.

      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
      be searched for LOC RRs later.

   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
      more subnet levels to search.  We now pop the top name from the
      stack and check for an associated LOC RR.  Repeat until a LOC RR
      is found.

      In this case, assume that inc-subsubnet.isi.edu does not have an
      associated LOC RR, but that div2-subnet.isi.edu does.  We will
      then use div2-subnet.isi.edu's LOC RR as an approximation of this
      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
      it will not be used if a subnet also has a LOC RR.)

5.3 Applicability to non-IN Classes and non-IP Addresses

   The LOC record is defined for all RR classes, and may be used with
   non-IN classes such as HS and CH.  The semantics of such use are not
   defined by this memo.

   The search algorithm in section 5.2.3 may be adapted to other
   addressing schemes by extending [RFC 1101]'s encoding of network
   names to cover those schemes.  Such extensions are not defined by
   this memo.











Davis, et al                  Experimental                      [Page 7]

RFC 1876            Location Information in the DNS         January 1996


6. References

   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
              STD 13, RFC 1034, USC/Information Sciences Institute,
              November 1987.

   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
              Specification", STD 13, RFC 1035, USC/Information Sciences
              Institute, November 1987.

   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
              Types", RFC 1101, USC/Information Sciences Institute,
              April 1989.

   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
            Definition and Relationships with Local Geodetic Systems;
            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
            138-R; CV, KV;

7. Security Considerations

   High-precision LOC RR information could be used to plan a penetration
   of physical security, leading to potential denial-of-machine attacks.
   To avoid any appearance of suggesting this method to potential
   attackers, we declined the opportunity to name this RR "ICBM".

8. Authors' Addresses

   The authors as a group can be reached as <loc@pipex.net>.

   Christopher Davis
   Kapor Enterprises, Inc.
   238 Main Street, Suite 400
   Cambridge, MA 02142

   Phone: +1 617 576 4532
   EMail: ckd@kei.com


   Paul Vixie
   Vixie Enterprises
   Star Route Box 159A
   Woodside, CA 94062

   Phone: +1 415 747 0204
   EMail: paul@vix.com





Davis, et al                  Experimental                      [Page 8]

RFC 1876            Location Information in the DNS         January 1996


   Tim Goodwin
   Public IP Exchange Ltd (PIPEX)
   216 The Science Park
   Cambridge CB4 4WA
   UK

   Phone: +44 1223 250250
   EMail: tim@pipex.net


   Ian Dickinson
   FORE Systems
   2475 The Crescent
   Solihull Parkway
   Birmingham Business Park
   B37 7YE
   UK

   Phone: +44 121 717 4444
   EMail: idickins@fore.co.uk































Davis, et al                  Experimental                      [Page 9]

RFC 1876            Location Information in the DNS         January 1996


Appendix A: Sample Conversion Routines

/*
 * routines to convert between on-the-wire RR format and zone file
 * format.  Does not contain conversion to/from decimal degrees;
 * divide or multiply by 60*60*1000 for that.
 */

static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
                                 1000000,10000000,100000000,1000000000};

/* takes an XeY precision/size value, returns a string representation.*/
static const char *
precsize_ntoa(prec)
        u_int8_t prec;
{
        static char retbuf[sizeof("90000000.00")];
        unsigned long val;
        int mantissa, exponent;

        mantissa = (int)((prec >> 4) & 0x0f) % 10;
        exponent = (int)((prec >> 0) & 0x0f) % 10;

        val = mantissa * poweroften[exponent];

        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
        return (retbuf);
}

/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
static u_int8_t
precsize_aton(strptr)
        char **strptr;
{
        unsigned int mval = 0, cmval = 0;
        u_int8_t retval = 0;
        register char *cp;
        register int exponent;
        register int mantissa;

        cp = *strptr;

        while (isdigit(*cp))
                mval = mval * 10 + (*cp++ - '0');

        if (*cp == '.') {               /* centimeters */
                cp++;
                if (isdigit(*cp)) {



Davis, et al                  Experimental                     [Page 10]

RFC 1876            Location Information in the DNS         January 1996


                        cmval = (*cp++ - '0') * 10;
                        if (isdigit(*cp)) {
                                cmval += (*cp++ - '0');
                        }
                }
        }
        cmval = (mval * 100) + cmval;

        for (exponent = 0; exponent < 9; exponent++)
                if (cmval < poweroften[exponent+1])
                        break;

        mantissa = cmval / poweroften[exponent];
        if (mantissa > 9)
                mantissa = 9;

        retval = (mantissa << 4) | exponent;

        *strptr = cp;

        return (retval);
}

/* converts ascii lat/lon to unsigned encoded 32-bit number.
 *  moves pointer. */
static u_int32_t
latlon2ul(latlonstrptr,which)
        char **latlonstrptr;
        int *which;
{
        register char *cp;
        u_int32_t retval;
        int deg = 0, min = 0, secs = 0, secsfrac = 0;

        cp = *latlonstrptr;

        while (isdigit(*cp))
                deg = deg * 10 + (*cp++ - '0');

        while (isspace(*cp))
                cp++;

        if (!(isdigit(*cp)))
                goto fndhemi;

        while (isdigit(*cp))
                min = min * 10 + (*cp++ - '0');




Davis, et al                  Experimental                     [Page 11]

RFC 1876            Location Information in the DNS         January 1996


        while (isspace(*cp))
                cp++;

        if (!(isdigit(*cp)))
                goto fndhemi;

        while (isdigit(*cp))
                secs = secs * 10 + (*cp++ - '0');

        if (*cp == '.') {               /* decimal seconds */
                cp++;
                if (isdigit(*cp)) {
                        secsfrac = (*cp++ - '0') * 100;
                        if (isdigit(*cp)) {
                                secsfrac += (*cp++ - '0') * 10;
                                if (isdigit(*cp)) {
                                        secsfrac += (*cp++ - '0');
                                }
                        }
                }
        }

        while (!isspace(*cp))   /* if any trailing garbage */
                cp++;

        while (isspace(*cp))
                cp++;

 fndhemi:
        switch (*cp) {
        case 'N': case 'n':
        case 'E': case 'e':
                retval = ((unsigned)1<<31)
                        + (((((deg * 60) + min) * 60) + secs) * 1000)
                        + secsfrac;
                break;
        case 'S': case 's':
        case 'W': case 'w':
                retval = ((unsigned)1<<31)
                        - (((((deg * 60) + min) * 60) + secs) * 1000)
                        - secsfrac;
                break;
        default:
                retval = 0;     /* invalid value -- indicates error */
                break;
        }

        switch (*cp) {



Davis, et al                  Experimental                     [Page 12]

RFC 1876            Location Information in the DNS         January 1996


        case 'N': case 'n':
        case 'S': case 's':
                *which = 1;     /* latitude */
                break;
        case 'E': case 'e':
        case 'W': case 'w':
                *which = 2;     /* longitude */
                break;
        default:
                *which = 0;     /* error */
                break;
        }

        cp++;                   /* skip the hemisphere */

        while (!isspace(*cp))   /* if any trailing garbage */
                cp++;

        while (isspace(*cp))    /* move to next field */
                cp++;

        *latlonstrptr = cp;

        return (retval);
}

/* converts a zone file representation in a string to an RDATA
 * on-the-wire representation. */
u_int32_t
loc_aton(ascii, binary)
        const char *ascii;
        u_char *binary;
{
        const char *cp, *maxcp;
        u_char *bcp;

        u_int32_t latit = 0, longit = 0, alt = 0;
        u_int32_t lltemp1 = 0, lltemp2 = 0;
        int altmeters = 0, altfrac = 0, altsign = 1;
        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
        int which1 = 0, which2 = 0;

        cp = ascii;
        maxcp = cp + strlen(ascii);

        lltemp1 = latlon2ul(&cp, &which1);



Davis, et al                  Experimental                     [Page 13]

RFC 1876            Location Information in the DNS         January 1996


        lltemp2 = latlon2ul(&cp, &which2);

        switch (which1 + which2) {
        case 3:                 /* 1 + 2, the only valid combination */
                if ((which1 == 1) && (which2 == 2)) { /* normal case */
                        latit = lltemp1;
                        longit = lltemp2;
                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
                        longit = lltemp1;
                        latit = lltemp2;
                } else {        /* some kind of brokenness */
                        return 0;
                }
                break;
        default:                /* we didn't get one of each */
                return 0;
        }

        /* altitude */
        if (*cp == '-') {
                altsign = -1;
                cp++;
        }

        if (*cp == '+')
                cp++;

        while (isdigit(*cp))
                altmeters = altmeters * 10 + (*cp++ - '0');

        if (*cp == '.') {               /* decimal meters */
                cp++;
                if (isdigit(*cp)) {
                        altfrac = (*cp++ - '0') * 10;
                        if (isdigit(*cp)) {
                                altfrac += (*cp++ - '0');
                        }
                }
        }

        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));

        while (!isspace(*cp) && (cp < maxcp))
                                           /* if trailing garbage or m */
                cp++;

        while (isspace(*cp) && (cp < maxcp))
                cp++;



Davis, et al                  Experimental                     [Page 14]

RFC 1876            Location Information in the DNS         January 1996


        if (cp >= maxcp)
                goto defaults;

        siz = precsize_aton(&cp);

        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
                cp++;

        while (isspace(*cp) && (cp < maxcp))
                cp++;

        if (cp >= maxcp)
                goto defaults;

        hp = precsize_aton(&cp);

        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
                cp++;

        while (isspace(*cp) && (cp < maxcp))
                cp++;

        if (cp >= maxcp)
                goto defaults;

        vp = precsize_aton(&cp);

 defaults:

        bcp = binary;
        *bcp++ = (u_int8_t) 0;  /* version byte */
        *bcp++ = siz;
        *bcp++ = hp;
        *bcp++ = vp;
        PUTLONG(latit,bcp);
        PUTLONG(longit,bcp);
        PUTLONG(alt,bcp);

        return (16);            /* size of RR in octets */
}

/* takes an on-the-wire LOC RR and prints it in zone file
 * (human readable) format. */
char *
loc_ntoa(binary,ascii)
        const u_char *binary;
        char *ascii;
{



Davis, et al                  Experimental                     [Page 15]

RFC 1876            Location Information in the DNS         January 1996


        static char tmpbuf[255*3];

        register char *cp;
        register const u_char *rcp;

        int latdeg, latmin, latsec, latsecfrac;
        int longdeg, longmin, longsec, longsecfrac;
        char northsouth, eastwest;
        int altmeters, altfrac, altsign;

        const int referencealt = 100000 * 100;

        int32_t latval, longval, altval;
        u_int32_t templ;
        u_int8_t sizeval, hpval, vpval, versionval;

        char *sizestr, *hpstr, *vpstr;

        rcp = binary;
        if (ascii)
                cp = ascii;
        else {
                cp = tmpbuf;
        }

        versionval = *rcp++;

        if (versionval) {
                sprintf(cp,"; error: unknown LOC RR version");
                return (cp);
        }

        sizeval = *rcp++;

        hpval = *rcp++;
        vpval = *rcp++;

        GETLONG(templ,rcp);
        latval = (templ - ((unsigned)1<<31));

        GETLONG(templ,rcp);
        longval = (templ - ((unsigned)1<<31));

        GETLONG(templ,rcp);
        if (templ < referencealt) { /* below WGS 84 spheroid */
                altval = referencealt - templ;
                altsign = -1;
        } else {



Davis, et al                  Experimental                     [Page 16]

RFC 1876            Location Information in the DNS         January 1996


                altval = templ - referencealt;
                altsign = 1;
        }

        if (latval < 0) {
                northsouth = 'S';
                latval = -latval;
        }
        else
                northsouth = 'N';

        latsecfrac = latval % 1000;
        latval = latval / 1000;
        latsec = latval % 60;
        latval = latval / 60;
        latmin = latval % 60;
        latval = latval / 60;
        latdeg = latval;

        if (longval < 0) {
                eastwest = 'W';
                longval = -longval;
        }
        else
                eastwest = 'E';

        longsecfrac = longval % 1000;
        longval = longval / 1000;
        longsec = longval % 60;
        longval = longval / 60;
        longmin = longval % 60;
        longval = longval / 60;
        longdeg = longval;

        altfrac = altval % 100;
        altmeters = (altval / 100) * altsign;

        sizestr = savestr(precsize_ntoa(sizeval));
        hpstr = savestr(precsize_ntoa(hpval));
        vpstr = savestr(precsize_ntoa(vpval));

        sprintf(cp,
                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
                %sm %sm %sm",
                latdeg, latmin, latsec, latsecfrac, northsouth,
                longdeg, longmin, longsec, longsecfrac, eastwest,
                altmeters, altfrac, sizestr, hpstr, vpstr);




Davis, et al                  Experimental                     [Page 17]

RFC 1876            Location Information in the DNS         January 1996


        free(sizestr);
        free(hpstr);
        free(vpstr);

        return (cp);
}













































Davis, et al                  Experimental                     [Page 18]