Where in the world is netgeo. caida. org？（2000年）

https://www.caida.org/catalog/papers/2000_inet_netgeo/inet_netgeo/

David Moore
(info@caida.org)
Cooperative Association for Internet Data Analysis (CAIDA)
University of California, San Diego
USA

Ram Periakaruppan
(ramanath@cs.colorado.edu)
Cooperative Association for Internet Data Analysis (CAIDA)
University of Colorado, Boulder
USA

Jim Donohoe
(jim.donohoe@computer.org)
Cooperative Association for Internet Data Analysis (CAIDA)
University of California, San Diego
USA
k claffy
(kc@caida.org)
Cooperative Association for Internet Data Analysis (CAIDA)
University of California, San Diego
USA

引用次数：134

Moore D, Periakaruppan R, Donohoe J, et al. Where in the world is netgeo. caida. org[C]//Proc. of the INET. 2000, 2000.

一、Introduction

当你的数据包通过互联网传输时，它们到底去了哪里?您的网站有多少用户生活在欧洲?您的互联网服务将如何受到新的跨太平洋电缆的影响?要回答这些问题，你需要地理信息。互联网研究人员经常需要将他们观察到的数据映射到特定的地方。但是IP地址、自治系统编号和主机名是逻辑层次中的值;它们不包含地理信息。由于没有权威的数据库将这些标识符映射到位置，因此必须使用多个网络信息来源，而这些来源可能是冲突的或不完整的。互联网研究中所使用的典型数据集的规模使得手动映射成千上万的IP地址变得不切实际和不精确;需要一个自动化的解决方案。本文介绍了一个克服这些障碍的工具NetGeo。

NetGeo是一个将IP地址、域名和自治系统(AS)编号映射到地理位置的工具。NetGeo在支持各种任务方面具有巨大的潜力:自动选择地理上邻近的镜像站点;ISP在何处部署新基础设施的决策，资费政策研究的流量分析;区域广告设计等。NetGeo目前被用于图形化的traceroute工具和研究国家之间的连接和交通流。

可以通过web、Java和Perl api交互式地访问NetGeo。NetGeo后端由一个数据库和一组用于地址解析和whois记录启发式分析的Perl脚本组成。为了减少whois服务器的负载和提高性能，NetGeo缓存了以前查询中解析的地理信息。

在网络地理信息系统(NetGeo)发展之前，互联网上的地理信息并不容易获得。随着研究人员意识到它的可用性，我们期待着对该工具的许多创造性使用。

二、NetGeo Overview

NetGeo旨在提取和处理关于网络实体的所有可用地理信息(IP地址、域名或机器名称或AS号)，以给出最可能的纬度和经度，位置的来源和特异性，以及结果可靠性的衡量标准。为了实现这一目标，NetGeo必须整理来自多个来源的位置信息。因为用于整合和比较地理信息的启发式开发正在进行中，并且依赖于上下文，所以NetGeo允许直接控制用于本地化的信息源。

NetGeo当前允许查找以下类型的标识符:数字、IP地址、域名和机器名。对于每次查找，NetGeo返回一条记录，其中包含:位置、位置的数据源、确定位置的粒度和额外的元数据(查询日期、上一次whois更新日期和使用的服务器)。location部分包含城市、州/省/行政单位、国家、纬度和经度的字段。图1显示了域名caida.org的示例记录。

图1 - NetGeo基于whois查找caida.org域名的结果记录。

当用户发起查找时，NetGeo使用请求的查找类型和标识符类型来确定哪种机制将提供最准确的结果。对于某些机制，NetGeo拥有确定位置所需的所有信息;对于其他机制，NetGeo必须查询外部数据库。因为外部查找消耗远程服务器(whois、DNS)和NetGeo本身的资源，所以NetGeo试图尽可能缓存来自外部查询的结果。

除了用于查找确定的远程数据库查询的框架之外，NetGeo架构还使用其内部数据库来解析查询结果。

三、Internal Databases

NetGeo使用由静态表和动态表组成的关系数据库。静态表用于识别whois记录中的位置名称，包含大约100,000个城市、行政区划(例如州、省、部门)和国家的经纬度值。我们这个数据集的主要来源是Getty研究所的地理名称辞典数据库(Getty)。动态表缓存派生的结果，以消除重复的外部查询和在将来的NetGeo查找期间的解析。

NetGeo地址解析器是一个知识导向的解析器——它只能识别包含在其数据库中的位置名称。对于许多位置，NetGeo表包含几种不同的拼写，或几种语言的位置名称，例如西班牙和西班牙语。名称存储在标准的26个字母的英语字母表中，因此España存储为Espana。

除了位置名称表，NetGeo数据库还包含其他几个静态表:美国邮政编码及其相关位置;行政单位名称;以及对应国家的电话号码。行政单位的名称有时在地址中明确列出，例如，在俄罗斯，许多地名以“共和国”和“RESPUBLIKA”作为后缀。解析器使用管理单元名称表来隔离和识别特定的位置名称。

动态表缓存先前NetGeo whois查询的结果，包括原始的查询目标(如IP地址)和完整的定位结果。这些表允许NetGeo快速响应频繁的相同查询，从而避免对外部服务器的不必要的重复查询。

此外，NetGeo使用包含正则表达式的规则文件从某些类别的机器名称中提取城市名称和机场代码，特别是那些在网络骨干中使用的机器名称。

四、Methods for Location Mapping

理想情况下，任何互联网地址对应的经纬度都可以通过DNS LOC记录获得[RFC1876]，每个AS号都有一个包含完整地址的whois记录。实际上，因为让DNS工作不需要LOC资源记录，所以很少有网络管理员支持它们。NetGeo可以使用DNS LOC记录(如果可用的话)，但主要依靠两种其他本地化技术:whois注册记录[RFC954]和专门的主机名规则文件。基于whois的结果偶尔会精确定位物理站点之外的位置，但NetGeo在大多数情况下都能够获得可接受的结果。

用户提供的关于待映射实体的附加信息可能会提高结果的准确性。GTrace [GTrace]是一个地理traceroute工具，它是将NetGeo与一组独立的启发式规则结合使用以提高准确性的一个很好的例子。

五、whois

NetGeo使用whois来查找三种类型的网络标识符的位置:域名、数字和IP地址。一个特定的主机可以与一个或多个这样的标识符相关联。当NetGeo使用whois定位主机时，它实际上是在查找注册联系人的地址或位置，这些地址或位置可能与机器的物理位置有关，也可能与机器的物理位置无关。例如，机器分布在许多州甚至国家的大公司通常用公司总部的地址注册域名，而不管机器的实际位置。虽然这种做法妨碍了主机的准确放置，但对于基于行政或政治边界的分析是有用的，例如，将IP地址与瑞士公司连接起来。

对于NetGeo来说，将互联网标识符映射到地址的第一步是从whois服务器上获取目标实体的whois记录。NetGeo有一个whois服务器主机名的列表和它们所需的查询格式。在最简单的情况下，通过对一个whois服务器的一次查询就可以找到所需的whois记录。有些查询需要多个查询，中间解析响应来指示下一步要查询的whois服务器。

1、AS Numbers

AS Numbers是最容易本地化的网络标识符，因为它们的数量相对较少，每个都用一个唯一的16位整数表示。最多有3台whois服务器(ARIN、RIPE和APNIC)，其中每台服务器只需要一次查询。此外，使用NetGeo进行的许多查找表明，与其他whois记录相比，AS号码的whois记录更有可能具有可解析的地址信息。

2、IP Addresses

同样的注册商，ARIN, mature和APNIC，共同负责IP地址空间的管理。授予接收组织的IP地址块的大小和起始地址随着时间的推移发生了变化，因此他们当前的分配策略[ENTITY-ALLOC]并不总是准确地描述旧组织持有的IP地址块。此外，接收组织可以向其客户或其他组织注册其地址块的细分。由于这些嵌套块的潜在存在，NetGeo有时必须发出多个whois请求来查找最合适的记录。子块注册允许确定给定主机的更具体的地理位置。

3、Domain Names

不同于AS数字和IP地址块，whois服务器对域名的责任是高度分布式的。虽然有区域性注册中心，但许多顶级国家域名都有独立的注册中心和whois服务器。也有独立的。gov、。mil和。edu名称空间注册表。最近，。com，。org和。net域名注册系统转变为分布式模式，在这种模式下有许多注册中心得到了ICANN的批准。对于这三个顶级域名(tld)中的域名，NetGeo首先查询一个单一的中心站点(Internic)，该站点提供一个指向包含所请求记录的实际注册表的指针。

一旦从whois服务器检索到记录，它需要被解析提取位置信息。(见附录:whois记录解析)

六、Hostname

虽然NetGeo基于whois的技术对于靠近网络边缘的小型组织来说是合理的，但对于地理上分散的大型组织来说，它们经常失败，因为whois记录将所有主机映射到该组织的注册总部。例如，来自核心骨干(传输)提供商的大多数设备，通常属于。net域，被部署在与ISP的whois记录没有关系的地方。来自大型网站组织(如IBM)的主机也面临类似的本地化挑战。

就ISP中转骨干网而言，其主机名往往包含城市名称/缩写或机场代码等地理信息。NetGeo使用基于规则的域解析文件来提取这些地理提示。例如，ALTER。NET (MCI/WorldCom的一部分UUNET使用的域名)将其部分路由器接口命名为三个字母的机场代码，如下所示:

    **EWR****BOS****SCL****ATL**

这种技术也适用于其他带有地理信息的tld。例如，ibm.com上的whois查询显示，*.almaden.ibm.com的主机可能在加州圣何塞的IBM阿尔马登研究中心，而不是在纽约。

图2 - ALTER.NET的域解析文件示例。

图2显示了ALTER的NetGeo域解析文件的一个示例。网络主机。该文件首先定义正则表达式，然后定义任何特定于域的异常。用户可以使用下面的格式通过城市或纬度/经度值识别异常的位置:

图2中的第一行定义了一个替换操作，当它与193.ATM8-0-0.GW2.EWR1.ALTER匹配时。NET，将返回“EWR”。第一行最后一个“/”后面的内容告诉NetGeo如何处理成功的匹配:在本例中，首先在当前文件中检查匹配项，然后在机场数据库中检查匹配项。

首先检查域解析文件的原因是，有时给定域的命名方案不一致。例如，搜索从198.ATM60.XR2.SCL1.ALTER获得的SCL。NET中的机场数据库将返回圣地亚哥·德智利的位置。改动。NET使用标准的机场代码和独立的、非标准的美国城市的三个字母缩写(图2说明了三个这样的缩写)。检测此类异常需要规则文件中的附加信息。

有时，网络服务提供商在命名他们的主机时，会使用多个地理位置提示。例如VERIO。NET将它们的一些主机命名为如下格式:den0.sjc .verio.net，这表明了接口的源和目标。没有办法自动区分源和目标;域解析文件必须包含这个特定于域的信息。

域名解析文件中的正则表达式是必要的，因为存在超过10,000个有效的机场代码[airport - codes]，如果没有大量误报，任意匹配三个字母的组合是不切实际的，甚至是不可能的。额外的信息，如到主机的往返时间，有助于消除误报，因为IP分组的传播速度不能超过光速。

基于主机名的映射的一个优点是，人们可以将整个域描述为一组规则，而不需要whois对域中的每个主机进行查找。然而，对于不使用内部一致命名方案的域，这种技术将失败。

七、DNS LOC

基于whois和基于主机名的映射都依赖于这样的假设:在没有明确位置信息的情况下，需要有根据的猜测。虽然RFC1876 [RFC1876]定义了一个DNS扩展来提供一个LOC资源记录类型，允许管理员将纬度和经度信息与条目关联，但它实际上是非常有用的。首先，RFC只指定了新字段的格式和解释，而没有确定在何处或以何种粒度使用它。因此，查找适当的LOC资源记录可能需要多次DNS查询。

更重要的是，人们不使用它。NetGeo目前默认不使用DNS LOC查询，因为它们的低成功率无法证明需要进行三次或三次以上的DNS查找以排除有效的DNS LOC记录的存在是合理的。

由于NetGeo除了纬度和经度之外还提供位置信息(城市、州、国家)，因此当NetGeo找到DNS LOC记录时，它需要将纬度/长度值映射到其内部数据库中包含的已知位置。在给定的容错范围内，它使用在其数据库中可以找到的最接近的匹配纬度/长度。这种方法可能会有问题:尽管NetGeo知道超过93000个独特城市位置的纬度和经度，但它们不一定具有代表性或在世界各地分布均匀。对于靠近国家边界的位置，结果匹配甚至可能不属于正确的国家。

八、Problems with whois Based Lookups

1、AS Numbers

三个注册商，ARIN, RIPE和APNIC，共同负责AS号码记录。根据当前的分配策略[ENTITY-ALLOC]，有时在适当的服务器上无法找到所有AS号项。因此，可能需要对所有三个服务器进行查询，以定位特定的AS数字记录，或者确定不存在这样的记录。

2、IP Addresses

与数字一样，并非所有的IP地址块记录都在正确的注册表中找到。由于历史原因，同一个块可能有多个注册中心的记录，并且这些记录可能不一致。虽然了解目前的政策可以帮助确定哪个登记处是权威的，但在某些情况下，目前权威的登记处缺乏在以前负责的登记处中找到的信息。此外，这种验证方法需要密切跟踪用于划分IP地址空间管理的策略。

由于可能存在大小未知的嵌套分配，因此单个IP地址的查找可能无法提供附近地址的信息。在某些情况下，邻近的地址会映射到不同的细分，否则这些细分就会被掩盖(参见图3和图4)。如果整个IP分配块集一次性可用(从数据库dump [RIPE-DB] [APNIC-DB])，那么就有可能正确地为所有IP地址范围建立位置表。然而，只使用标准的whois查询有两种选择:只存储单个IP地址，而不是范围;或者存储较大的范围，但知道一些较小的细分可能会被掩盖。NetGeo目前存储包含256或更少IP地址的所有子块的记录。对于地址块中包含超过256个地址的主机，仍然需要一个地址项。

3、Domain Names

不幸的是，这些不同的注册中心返回的记录还没有标准格式，而且有比as号和IP地址记录更广泛的格式。此外，目前围绕着。com、。org和。net空间的政治框架允许任意新的注册者以未知的记录格式在任何时间出现。正如附录中所讨论的，在NetGeo中精确定位在很大程度上依赖于记录的结构。也可以使用更通用的匹配算法，但这种算法的速度可能会慢得多，并且错误匹配的可能性会增加。

图3显示了对单独细分块的查找，其中整个直接父块被完全细分。查找X.Y.0.1 (a)会得到范围X.Y.0.0/16和X.Y.0.0/17的记录。由于X.Y.0.0/17是最具体的范围，因此解析该记录以获取位置信息。类似地，查找X.Y.128.1 (b)会得到X.Y.0.0/16和X.Y.128.0/17的记录。查找顺序(a)和(b)无关紧要。

图4演示了对部分但不完全分区的块进行查找时的模糊性。查找X.Y.0.1 (A)会得到范围X.Y.0.0/16和X.Y.0.0/17的记录。因为X.Y.0.0/17是最具体的范围，它的记录用于查找位置信息。但是，查找X.Y.128.1 (b)只会得到X.Y.0.0/16的记录。因此，如果在(b)之前查找(a)，那么X.Y.0.0/16和X.Y.0.0/17的记录都将存储在数据库中。但是，如果在(a)之前查找(b)， (b)的查找将存储X.Y.0.0/16的记录，而(a)的后续查找将与(b)的记录在数据库中匹配，从而防止注册中心查询正确的记录。

九、Future Work

我们对NetGeo潜在用途的想法超出了我们所拥有的资源。由于查询的外部数据库的记录格式和策略都在快速变化，因此维护当前系统需要相当大的工作量。NetGeo的解析脚本必须进行修改，以适应任何whois服务器记录格式的每一个变化。随着使用非标准格式的icann授权注册商的激增，我们可能需要实现以性能换取通用性的解析器。较少优化的启发式方法可以更好地处理来自新服务器的输出多样性。

由于IP地址块和AS号仅由3个注册中心管理，因此可以将这3个数据库直接存储在NetGeo中以节省大量的查询流量。特别是，APNIC和RIPE将他们的数据库公开，我们正在与NSI合作，以获得对他们数据库中网络地理相关字段子集的批量访问。尽管合并这样的数据库将需要对NetGeo进行重大的架构更改，但它们将允许研究子分配行为——注册表如何进一步分配IP地址的子块，以及产生的子分配层次结构。

在其当前形式中，NetGeo每次查找都只基于来自用户的一条网络标识信息(IP地址、域名或主机名或AS号)。未来的版本将允许用户使用单个实体的额外标识符和信息来增强NetGeo的决策过程，从而提供更准确的定位。例如，查找用户可能提供的单个实体:多个IP地址(例如，来自同一路由器)，多个转发DNS名称，一组包含该实体的traceroute路径，RTT信息，等等。

我们还想校准NetGeo定位的准确性。这将涉及将多种技术提供的结果与已知值进行比较。虽然验证成千上万的映射是一个挑战，其他的信息来源，包括由CAIDA的skitter测量项目[skitter]跟踪的路径，可以帮助验证过程。

十、Related Work

Digital Island的TraceWare产品[TraceWare]维护着一个与国家代码相关的IP地址数据库。它旨在支持基于HTTP查询源的web内容定制。他们的技术正在申请专利，因此与NetGeo技术的具体关联是未知的。

在UIUC的Pablo研究小组支持IP到纬度/经度服务[UIUC- ip2ll]，使用Internic的whois数据库。它将美国站点解析为它们的城市，加拿大站点解析为它们的省，其他非美国站点解析为该国的首都。此服务器不处理.mil域。

其他的地理traceroute服务器包括VisualRoute [VisualRoute]、WhatRoute [WhatRoute]、GeoBoy [GeoBoy]和NeoTrace [NeoTrace]，它们使用自己的技术在地理地图上定位IP地址，一般依赖于静态的地图数据库和whois信息。

Uri Raz [Raz]维护一个列出资源的网页，以方便手动发现主机的地理位置。Christopher Davis [Davis]维护一个网页，以帮助管理员轻松地将LOC记录输入到他们的DNS配置文件中。

十一、Acknowledgements

这项工作是由美国国家科学基金会资助的ANI-9996248，作为CAIDA的互联网地图集项目的一部分。其他的赞助者包括APNIC、ARIN、NSI和成熟的NCC注册中心。盖蒂研究所的地理名称辞典是地理位置信息的宝贵来源。对于他们所有的bug报告和性能投诉，我们感谢Brad Huffaker和其他在CAIDA内部的NetGeo用户。特别感谢Colleen Shannon在本文写作过程中的支持和编辑。kc claffy对互联网可视化特性需求的持续坚持为这项工作提供了动力。

十二、Conclusion

CAIDA开发了NetGeo来支持它的几个互联网拓扑可视化项目，NetGeo已经成为我们许多分析的重要组成部分。然而，我们的努力还没有开始意识到网地网的潜力。一些组织已经表示有兴趣使用NetGeo来选择内容下载的最佳镜像站点，将基于web的内容定位到特定的用户区域，开发用于映射网络的工具，并为ISP基础设施扩展提供宝贵的指导。NetGeo可以支持许多带有地理问题的互联网研究问题的调查，并可以与许多网络可视化和教育工具相结合。

NetGeo提供了许多其他已知服务所没有的功能:对城市粒度的解析，广泛的whois服务器源，使用最近查询结果的缓存来提高性能，以及交互式和基于api的公共数据库访问。随着对NetGeo可用性的了解在整个研究界传播，我们预计NetGeo的功能会有许多新的用途。

将网络实体映射到地理位置的问题是困难的，需要许多启发式方法并利用尽可能多的独立信息源。信息源格式的变化、信息的动态特性以及互联网的普遍增长使这一过程更具挑战性。

Perl和Java客户端接口可以在http://netgeo.caida.org/上找到。

十三、References

|[GETTY]|

The Getty Thesaurus of Geographic Names,
Getty Thesaurus of Geographic Names (Getty Research Institute)

Davis, C., Vixie, P., Goodwin, and T. Dickinson, "A Means for Expressing Location Information in the Domain Name System", January 1996.
http://www.ietf.org/rfc/rfc1876.txt

Harrenstien, K., Stahl, M., and E Feinler, "NICNAME/WHOIS", RFC 954, October 1985.
http://www.ietf.org/rfc/rfc0954.txt?number=954

Periakaruppan, R., Nemeth, E., "GTrace - A Graphical Traceroute Tool", USENIX LISA'99, November 1999.
Index of /catalog/software/gtrace/paper

Asian Pacific Network Information Center, Division of IPv4 Address Space and AS Numbers Among Registries,
http://www.apnic.net/db/RIRs.html

Smith, D., Listing of Airport Codes,
Worldwide Airport Codes

Réseaux IP Européens Network Coordination Centre, Available Databases,
ftp://ftp.ripe.net/ripe/dbase/

Asian Pacific Network Information Center, Available Databases,
ftp://ftp.apnic.net/pub/apnic/dbase/data/

McRobb, D., Skitter,
https://www.caida.org/catalog/software/skitter/

TraceWare, Digital Island,
http://www.digisle.net/services/app_serv/traceware.shtml (Expired Link)

UIUC's IP to Lat/Long Server,
http://cello.cs.uiuc.edu/cgi-bin/slamm/ip2ll/

VisualRoute, Datametrics System Corporation,
http://www.visualroute.com/

WhatRoute, Bryan Christianson,
http://homepages.ihug.co.nz/~bryanc/

GeoBoy, NDG Software,
http://www.ndgsoftware.com/~ndgprod/page11.html

NeoTrace, A Graphical Traceroute Tool,
http://www.neoworx.com/products/neotrace/default.asp

Raz, Uri, Finding a host's geographical location,
http://www.private.org.il/IP2geo.html

Davis, C., DNS LOC: Geo-enabling the Domain Name System,
DNS LOC: Geo-enabling the Domain Name System

||

十四、 Appendix: whois Record Parsing

whois记录的地址解析包含5个步骤，每个步骤都可能重复。NetGeo继续地址解析过程，直到它识别一个位置，最好是一个城市和州(或省、地区、区等)，但有时只是州或可能只有国家。在极少数情况下，whois记录中没有可识别的位置信息，解析器无法确定任何粒度级别的位置。

我们列出并详细描述了地址解析中使用的五个步骤:

1、从whois记录中提取地址字符串

2、搜索国家指标

3、标准化地址字符串

4、解析地址字符串，确定位置(国家，州，城市)

5、查找位置对应的纬度和经度

NetGeo逐行遍历whois记录时并行执行步骤(1)和(2)。

当解析成熟或APNIC记录时，通常需要遍历步骤(1)到步骤(4)，在记录中找到的几个地址字符串块中搜索一个可识别的地址。NetGeo可以多次解析一个地址字符串块;如果它发现一个新的国家指示符，它将尝试使用这个国家作为重新解析地址字符串块的提示。这种技术对于缺少国家名称或代码的地址块很有用。

用于包含邮政编码的美国地址的过程稍微简单一些。在提取过程中，NetGeo搜索美国邮政编码(在正确的上下文中为5或9位数字的字符串)，并将找到的任何字符串与邮政编码数据库进行比较。如果匹配，NetGeo可以跳过其余的解析过程并本地化邮政编码。

1、从whois记录中提取地址字符串

这一步从记录中提取可能包含地址的一行或多行。从ARIN或Internic whois服务器返回的记录中提取地址是很简单的。地址，如果存在，紧跟在包含注册者姓名的行之后。从成熟的APNIC服务器返回的记录中提取地址比较困难;这些记录经常包含多个地址，并且地址行标记不一致。所有注册表中都存在不完整的地址。

例如:来自ARIN的whois记录。

ARIN whois服务器(whois.arin.net)查找IP地址192.149.252.22 (ARIN whois服务器本身的地址)时返回以下记录。不用于地址解析的行被省略了。

在这个例子中，从记录中提取的地址是:

在ARIN和Internic记录中的地址经常是这种格式，城市，州和zip都在一行上。当NetGeo检测到city-state-zip线路，并且邮政编码与数据库中的值匹配时，NetGeo将停止任何进程中的解析。如果没有这条标识线，NetGeo将提取上述行以及“US”行。

例如:来自RIPE的whois服务器

成熟whois服务器(whois.ripe.net)返回以下记录查找IP地址193.0.0.200(成熟whois服务器本身的地址)。不用于地址解析的行被省略了。

在这个例子中，提取的第一组地址字符串是:

如果NetGeo解析器无法从上述地址块中识别位置，它将提取第二个地址块:

如果可能，NetGeo从第一组标记为"descr:"的行中提取地址字符串。如果没有这样的组，或者组中的字符串不包含可识别的位置，解析器将从标记为“address:”的行中提取地址字符串。我们更喜欢来自“descr:”行的数据，因为“address:”行指的是联系人个人的地址，而不是注册实体本身。

APNIC记录的结构与成熟记录类似，因此地址字符串的提取与上面的例子类似。

2、搜索国家指标

当NetGeo从记录中收集地址字符串时，它会测试每个地址字符串中是否有可能表示该国家的值。除了从地址字符串中解析国家名称或国家代码外，还使用了以下技术:

（1）在成熟和APNIC记录中，NetGeo查找标有“country:”的行;这样的一行通常包含两个字母的ISO 3166国家代码。第(1)节中的成熟记录示例包含一个“country:”行，因此解析器将识别随后的“NL”国家代码。

（2）NetGeo在“netname:”字段中查找完整的国家名称，例如“cip -比利时- regional”。为了防止错误匹配，NetGeo只接受完整的国家名称，而不接受在网络名称中嵌入的国家代码。

（3）NetGeo在记录中查找国际电话代码，并将电话代码映射到某个国家。在上面的示例中，联系信息块包含电话号码“+31 20 535 4444”，电话代码“31”对应荷兰。对于许多国家来说，国家内的区号可以进一步本地化记录。在这个例子中，“20”区号表示联系人在阿姆斯特丹。

（4）NetGeo在记录中查找具有两个字母的顶级域名(TLD)的电子邮件地址;它将使用来自“e-mail:”行的第一个TLD为2个字母的电子邮件地址，否则使用来自任何类型行的第一个TLD为2个字母的电子邮件地址。在上面的示例中，联系人的电子邮件地址“ops@ripe.net”具有通用的TLD，因此不能用来猜测国家。在某些记录中，地址可能是“ops@ripe.nl”，其中两个字母的TLD“nl”本地化了记录。

3、标准化地址字符串

将地址字符串中的字符映射为标准的26个大写ASCII字母，例如“España”->“ESPANA”。字符串用逗号分隔成单独的行，这些行通常将城市名称与州或省的名称分开。对于非美国地址，将删除包含数字(假定为邮政编码)的标记。例如，下面是三个原始的地址字符串:

变成4个标准化的地址字符串:

缩略语中使用的句号被删除，例如“N.Y.”。- - - - - - >“纽约”。作为一个单独的单词出现的“Saint”被映射为“ST”，例如“Saint Paul”->“ST Paul”。这些规范的格式允许与存储在数据库中的名称进行高效的比较。

4、解析地址字符串，确定位置(国家，州，城市)

地址解析从标准化地址字符串块的最后一行开始，一直到第一行。解析将继续，直到找到一个城市(如果可能的话)。解析器试图找到国家(如果还不知道)，然后是州或省，然后是城市。

找到国家名称或代码后，解析器尝试在国家之前的行中，或在国家之前的标记中查找州或省的名称。在搜索城市或州时，解析器试图找到最长的右锚定标记集合，这些标记形成当前国家的有效城市或州名称。

例如，地址字符串可能包含街道地址、城市名称和不带逗号的州的缩写。在这个例子中，假设国家已经确定为美国，州是加利福尼亚州。

在标准化之后，它变成了:

解析器测试字符串"GILMAN DRIVE LA JOLLA"和"DRIVE LA JOLLA"，然后在数据库中找到与"LA JOLLA"匹配的字符串。在本例中，“LA JOLLA”是与当前州和国家的有效城市名称匹配的最长的右锚定标记集合。

如果没有右锚点标记集合与有效的城市名称匹配，解析器将尝试找到与有效的城市名称匹配的最长的左锚点标记集合。在这个例子中，如果没有识别出“LA JOLLA”，解析器将继续测试“GILMAN DRIVE LA”，然后是“GILMAN DRIVE”，最后是“GILMAN”。搜索左锚字符串对于跳过无法识别的州或国家缩写很有用。例如，如果标准字符串是“LA JOLLA california”，即使解析器不能识别非标准缩写“california”，它也可以识别左锚字符串“LA JOLLA”。

在搜索最长字符串时，解析器会忽略指定政府单位的标记，这在一些国际地址中很常见。例如，在解析俄语地址时，解析器忽略标记“REPUBLIC”或“RESPUBLIKA”，并尝试仅将共和国的名称与数据库中的值进行匹配。

在某些情况下，在数据库中找不到匹配项，因为候选位置名与数据库中存储的值在格式上略有不同。当包含连字符、撇号、嵌入空格的候选字符串与数据库条目匹配失败时，解析器使用修改后的候选字符串重试数据库查询。例如，地名“ST-PIERRE”和“Saint-Pierre”在数据库中存储为“ST-PIERRE”。像“ST . Pierre”这样的候选字符串最初会被转换为标准形式的“ST Pierre”，这将无法与数据库中的“ST- Pierre”条目匹配。解析器将使用修改后的表单“ST-PIERRE”执行查询，该查询将匹配数据库中的条目。

5、查找位置对应的纬度和经度

从whois记录中成功解析地址后，查找相应的经纬度值就很简单了。在这一步中，城市和/或州名已经根据数据库中的地名进行了验证，因此一个简单的数据库查询将返回纬度和经度(如果已知的话)。