Querying the RIPE Database
Some of this information is entered by the RIPE NCC, such as the IP address allocations and AS Number assignments that were given to a certain resource holder. Other information is entered by resource holders themselves, such as customer assignments, reverse DNS, routing and contact information.
People who want to query for this information have several options available to them, varying from a web interface to a command line tool, as well as a RESTful API. There are several ways in which you can influence the scope of your search. For example, you can query for a specific record identifier, do a free-text search, or perform a query that includes results from whois databases run by other Regional Internet Registries. This document will outline which query method will give you the best results.
2. Query Basics
The RIPE Database stores all information in records known as objects. These are blocks of text in a standard notation defined in the Routing Policy Specification Language (RPSL). An object has multiple fields, called attributes or keys, that each have a value. Here is an example of a role object, which describes a role performed by one or more people, such as an administrative or technical contact.
The formatted object in this example is created according to a template. There is a specific template for each object. Users have to stick to the template, as well as the syntax rules for each value, when creating an object in the RIPE Database. Here is the template for the role object.
Every attribute is marked as mandatory, optional, or whether the value is generated by the RIPE Database server. In addition, there is an indication if the attribute can only appear a single time, or if you can use it multiple times in the object. Finally, some attributes are flagged with a search key, which can be:
- a primary key
- a lookup key
- an inverse key
- Using the web interface on the RIPE NCC website
- Using telnet on port 43
- Using a whois client, included in most UNIX-like distributions
- Using the RESTful API
- https://rest.db.ripe.net/ripe
- AFRINIC
- APNIC
- ARIN
- LACNIC
- JPIRR
- RADB
- Adding missing mandatory attributes
- Wrapping unrecognised attributes with «remarks»
- Creating dummy objects for missing data to keep referential integrity
- Converting attribute values
- All these transformations are marked by «End Of Line» comments in the objects
The primary key is a unique identifier within a set of objects of the same type. In the case of the role object, the «nic-hdl:» is the only attribute you can be sure won’t appear in any other role object (unlike the «role:» attribute with the role’s name). Thus, in this example, searching for «RIPE NCC» might give you multiple results, but searching for «CREW-RIPE» will give you only one.
The lookup key is simply an attribute that is indexed, meaning that you can search for it. An inverse key allows you to search for all objects that reference that particular attribute value, which means you can for example do a query for ‘all objects that have this specific «mnt-by:» value’. You can find more more details and examples in the Advanced Queries section.
The primary, lookup and inverse key are paramount to keep in mind when querying the RIPE Database, because only these attributes are searchable. This means that when looking for a specific role object, you can find it by querying for the value in the «role:», «email:» or «nic-hdl:» attribute, but not by the looking for the «address:» or «phone:» value. Lastly, you can only do inverse queries on some attributes.
Please note that when searching for resources such as an IP address block or AS Number, contact information from related objects will automatically be returned as well. You can only query for a limited amount of personal information every day. After reaching that limit, you will be blocked from making further queries. To disable automatic queries for personal information, please use the «-r» flag, as explained in the Advanced Queries section.
Using Full Text Search
If you are looking for a specific piece of information and you don’t know one of the values required to find what you are looking for, you may consider using the Full Text Search instead of doing a standard query. Full Text Search treats the entire database as a flat text file and allows you to search for anything. The search is done on object text without regard for any relationships. As such, results may be very unstructured, but it can provide a good starting point for more specific standard queries later on. Keep in mind that Full Text Search is only available on the RIPE NCC website and not in other methods to query the RIPE Database.
3. Query Methods for the RIPE Database
There are four different ways to query the RIPE Database:
The web interface
For most use cases, the web interface provides a straightforward way to perform a RIPE Database query. With a simple check mark or radio button, you can easily broaden your search to include other databases, or narrow it down to only query for certain object types. If needed, you can switch to Full Text Search with a single click.
telnet on port 43
For users who prefer to query from the command line, you can open a telnet session to whois.ripe.net on port 43 and perform your query. After the result is returned the connection is automatically closed, unless you tell the RIPE Database to keep it open by using the «-k» flag.
A whois client
Alternatively, most UNIX-like operating systems are shipped with a whois client. These often add additional functionality and flexibility, but should be used with care. This is because the whois client itself accepts flags, but so does the RIPE Database. In addition, not every flag in every whois client implementation has the same meaning, for example in Linux versus BSD-based distributions. To ensure proper flag usage, refer to the man pages of your whois client.
The RESTful API
The RIPE Database also offers a RESTful API, which returns results in XML or JSON format. Your client should specify the desired response format using the Accept: header in the HTTP request or append an extension of .xml or .json to the request URL. The server will return a response in the appropriate format for that given extension. If the request fails, any error messages will be returned in the response body.
The URL for accessing the RESTful service is:
The full documentation for the RESTful API is available on Github.
4. Query Multiple Databases with the Global Resource Service
The RIPE Database only contains information related to IP addresses and ASNs that are managed by the RIPE NCC. So if you are querying for any random IP address that you would like more information on, you may get a specific result if the range is managed by the RIPE NCC, or you may find a generic placeholder that says the IP address belongs to a range managed by another Regional Internet Registry (RIR).
The RIPE NCC operates mirrors of the other RIRs’ databases as well as some of the major routing registries, known as the Global Resource Service (GRS). When enabling GRS, you can query for any resource and get an authoritative response from the appropriate source, which in addition to the RIPE Database includes:
Because the RIPE NCC is bound by Dutch and European data privacy laws, we are obliged to remove all personal data received from other databases. This is either removed at the source or stripped out and deleted during the transformation process. The RIPE NCC does not store any personal data from other registries. Where necessary, we create and reference dummy objects to keep data integrity intact.
Before importing the data we transform objects into RIPE RPSL syntax by carrying out the following steps:
To use GRS from the web interface, select the appropriate radio button below the search box. When using telnet or the whois command line client, add the «—resource» flag to your query to query only the dummified GRS databases, or the «-a» flag to query all available databases, i.e. GRS sources and the original RIPE Database combined.
Using the API, you can specify one or multiple GRS source names as parameters, e.g. «source=arin-grs» or «source=arin-grs&source=apnic-grs». For more information, please refer to the documentation on Github.
5. Advanced Queries
By default, when you perform a query all object types and lookup keys are searched for. In many cases you will want to look for more specific information, which can be achieved by selecting the appropriate check box or radio button in the web interface, or by adding a specific flag to the search query.
IP address queries
When doing IP address lookups, you may want to see ranges that are more or less specific than your query to get a better understanding of the relationship between the ranges. Here is an overview of the most common flags. The full list can be found in the Query Reference Manual.
| Flag | Result |
|---|---|
| -l | First level less specific query. It shows one level above the range your are querying, for example showing the allocation that a certain assignment is part of. |
| -L | All levels less specific query. This option returns all ranges that include the IP address or range in your query. Use this option to view any upstream IP address blocks associated with the query range. Viewing the upstream IP address range can be useful for network troubleshooting. |
| -m | First level more specific query. It shows one level below the range your are querying, for example showing all assignments that were made under a certain allocation. |
| -M | All levels more specific query. This option returns all more specific address ranges within the boundaries of the IP address range specified in the query. Use this option to view all suballocations and assignments made under an allocation. Use this option with care, as for example all levels more specific under a /8 will return so many results that it might leave you blocked from accessing the RIPE Database. |
| -d | When used with a hierarchical flag, then also include domain object types. |
Inverse queries
Inverse queries request all objects to be returned that reference the specified query argument in the attribute(s) specified in the query flag arguments. For example, it will allow you to find all objects in which a certain person is the administrative contact (admin-c), or it will allow you to find all route objects in which a certain ASN is referenced as the «origin:» attribute. Here is an overview of the most common inverse query flags. The full list can be found in the Query Reference Manual.
| Flag | Lookup key | Result |
|---|---|---|
| -i admin-c | NIC-handle | Objects with a matching «admin-c:» attribute. |
| -i tech-c | NIC-handle | Objects with a matching «tech-c:» attribute. |
| -i person | NIC-handle | Objects with matching «admin-c:», «tech-c:» or «zone-c:» attributes. |
| -i mnt-by | Maintainer | Objects with a matching «mnt-by:» attribute. |
| -i mnt-lower | Maintainer | Objects with a matching «mnt-lower:» attribute. |
| -i mnt-nfy | mntner objects with a matching «mnt-nfy:» attribute. | |
| -i mnt-routes | Maintainer | aut-num, inetnum and route objects with a matching «mnt-routes:» attribute. |
| -i origin | AS number | route and route6 objects with a matching «origin:» attribute. |
In the web interface, there is a separate tab that allows you to do inverse queries. Here is an example of the notation in the command line interface.
Miscellaneous
Requests a persistent connection. A client may issue multiple queries on the same connection. The server will not close the connection until it receives a -k without an argument (after the first one).
For a full overview of all query types and flags, please refer to the Query Reference Manual.
Трудности с Linux
Заметки по ходу настройки «разного» в Linux. Хочу разобраться — читаю исходники. Программирование, администрирование, микроэлектроника, фотографирование и пр.
Страницы
воскресенье, 22 апреля 2018 г.
RIPE database query
Существует такой ресурс в ipv4-сети, как RIPE database. RIPE https://www.ripe.net/ — сетевой координационный центр (RIPE NCC). Эта организация наблюдает за куском сети Интернет куда входит Европа и пока ещё другая территория.
Полезность её в том, что это база данных, во-первых, — актуальная база-данных, во-вторых, — уникальная актуальная база данных ip-сетей, в-третьих, а других таких нету в открытом доступе, в-четвёртых.
Как база данных RIPE по сетям может быть полезна простым гражданам, страдающим от постоянных проблем с интернет-связью?
Итак, допустим есть web-ресурс, пользователи которого, постоянно мешают нормальному функционированию сервера.
Нужно сделать так, чтобы не мешали. Одно из решений — ограничить доступ к собственному серверу, со стороны некоторой подсети.
Порядок:
1. Определяем ip-адрес, web-ресурса. Для этого используем встроенную в Linux команду nslookup.
nslookup domain
где domain — доменное имя веб-ресурса.
В качестве ответа получим один или несколько ip-адресов.
2. Идём на сайт RIPE в раздел запросов к базе данных RIPE. https://apps.db.ripe.net/db-web-ui/#/query
и ищём по ip-адресам из первого пункта.
3. Анализируем ответы базы данных RIPE. Потерпевших пользователей интересует строки inetnum, netname, descr.
inetnum — это диапазон ip-адресов, выданных посети netname, с человеческим описанием descr.
4. Идём в интерфейс нашего сервера, роутера и чего-ещё-там-есть у обычного пользователя и вносим полученную подсеть (диапазон ip-адресов) в ip-фильтр входящих соединений. Устанавливаем правило отбрасывать все соединения исходящие из этой вредной подсети.
Полезность этой процедуры, пока недооценена массами системных администраторов, но при должном подходе может быть эффект.
5. Сейчас, в конце апреля 2018 года, такая простая процедура, может помочь очень многим пользователям частных серверов.
Howto RIPE
Les démarches administratives pour obtenir un numéro d’AS et des adresses IP auprès du RIPE (Réseaux IP Européens) relèvent souvent de fantasmes pour les non initiés. Dans une optique de transparence, démystifions ces opérations.
Comment devenir LIR
Signer les documents d’inscriptions
Payer (environ 2000 EUR de frais d’accès, puis 1400 EUR par an)
On obtient un certain nombre de goodies 😉 et d’infos, notamment un objet ORG-* maintenu par le RIPE, vous pouvez dès maintenant faire un whois dessus /
Création des premiers objets RIPE
Via https://apps.db.ripe.net/startup/ on va créer un objet mntner et un premier objet person.
L’objet mntner créé servira à protéger tous les futurs objets (ils seront “mnt-by” cet objet).
On peut ainsi ajouter/modifier des objets sur https://www.db.ripe.net/fcgi-bin/webupdates.pl avec le mot de passe de l’objet mntner.
Demander une première Allocation
Via le LIR Portal, on va demander une première allocation d’adresses IPv4 et IPv6. Une allocation est une sorte de réserve d’adresses, dans laquelle on pourra assigner des blocs à des clients ou pour son propre usage.
Sur https://lirportal.ripe.net/requestforms/ : IPv4 First Allocation Request Form et IPv6 First Allocation Request Form
En IPv4, vous devriez obtenir une allocation d’un /22 (environ 1000 adresses IPv4).
En IPv6, vous obtiendez un /32 (des milliards de milliards de blocs).
Pour l’IPv4, le RIPE peut vous poser la question : “Est-ce qu’un /21 vous suffira pendant 6 mois ?” (et oui, la question est inverse de celle attendue) Ils vous demandront également de vous justifier (vous pourriez recevoir un appel venant des Pays-Bas 😉 Vous devez surtout justifier de votre intérêt global à devenir LIR et avoir vos propres adresses IP. Les justifications précises (nombre d’équipements, etc.) se feront lors de la demande d’assignment.
Voici votre ALLOCATED PA IPv4 :
Demander un Assignment
Un Assignment consiste à utiliser une partie de son Allocation. On assigne un ensemble d’adresses IP provenant de sa réserve d’adresses allouées pour un usage précis : cela peut être interne (sa propre infra, des serveurs dédiés standalone, etc.) ou pour des clients (l’assignment sera alors à leur nom).
Le tout premier assignment IPv4 devra être approuvé pour le RIPE. Il se fait via une demande sur le LIR Portal et devra être justifié très précisément (nombre d’équipements, marques, etc.).
Par la suite, si tout est bien géré (pas d’objets en erreur dans la base RIPE), les assignments suivants seront faits directement en créant des objets inetnum dans la base RIPE. Pour être précis, il faudra attendre 6 mois : c’est le principe de l’Assignment Window (AW) qui sera à 0 au départ puis évoluera à l’ensemble de votre Allocation (1024 pour un /22).
Voici un ASSIGNED PA IPv4 :
Les assignments IPv6 ne nécessitent aucune approbation du RIPE, même pour les premiers. On déclarera directement ses objets inet6num dans la base RIPE.
Voici un ASSIGNED PA IPv6 :
Demander un numéro d’AS (Autonomous System)
Si l’on va gérer l’annonce BGP de ses adresses IP obtenues, il est nécessaire d’obtenir un numéro d’AS (Autonomous System). Cela se fait simplement via le LIR Portal : sur https://lirportal.ripe.net/requestforms/ AS Number Request Form. Peu de justification sera nécessaire, la seule difficulté est que l’on demande de citer 2 numéros AS avec lesquels vous allez connecter : vous devez citer ici les opérateurs avec lesquels vous avez OU vous comptez avoir un contrat de transit (a priori il n’y a jamais de vérification sur ce point).
Vous allez obtenir un numéro d’AS sur 32 bits :
Annoncer ses adresses IP en BGP
Avant d’annoncer ses adresses IP en BGP, il faut créer un objet route (ou route6 en IPv6).
Vous pouvez maintenant configurer vos routeurs BGP pour annoncer vos adresses IP. Si vous aller gérer des débits de centaines de Gb/s, tournez vous Cisco, Juniper & co (et votre banquier). Sinon privilégiez les solutions libres comme http://trac.evolix.net/infogerance/wiki/HowtoQuagga ou HowtoOpenBSD/OpenBGPD
Gérer les reverses DNS
Pour gérer les reverses DNS d’adresses IPv4, il faut ajouter un champ mnt-domains à l’objet inetnum (PA ALLOCATED) puis ajouter un objet domain (domain: 8-11.5.3.in-addr.arpa) qui pointe vers vos serveurs DNS.
Attention, il faut préparer vos serveurs DNS avant d’ajouter l’objet domain ! Si vous utilisez http://trac.evolix.net/infogerance/wiki/HowtoBind, vous allez avoir des zones du type :
Du fait du fonctionnement du reverse DNS, on est obligé de créer de multiples blocs multiples de /24 (ou /16… mais peu probable)
Ajouter un rôle pour gérer les demandes d’abuse
Il faut désormais créer un rôle pour gérer les demandes d’abuse. On crée donc un objet role :
Il faut ensuite ajouter ce rôle via un champ abuse-c sur votre objet organisation. Pour cela vous devez passer par le LIR Portal : https://lirportal.ripe.net/dbobjects/edit/organisation (votre objet étant mnt-by: RIPE-NCC-HM-MNT)
Créer un bloc PI (adresses IP indépendantes)
En tant que LIR, on peut créer des blocs d’adresses IP indépendantes pour des clients, qui pourront faire à peu près ce qu’ils veulent de ce bloc (notamment changer de fournisseur de transit, voire même de changer de LIR).
Malheureusement, ce n’est plus possible en IPv4 à cause de la pénurie des adresses. Cela reste néanmoins possible en IPv6.
Dans un premier temps, il faudra créer un objet organisation et person, au nom du client qui veut le bloc PI).
Ensuite, sur https://lirportal.ripe.net/requestforms/ : IPv6 Provider Independent (PI) Assignment Request Form
Vous allez devoir justifier votre demande comme pour un Assignment classique (moins essentiel en IPv6). Vous devrez notamment fournir des informations administratives sur le client et également le contrat que vous avez signé avec le client ! Vous devez d’ailleurs inclure dans ce contrat des mentions obligatoires fournies par le RIPE.
Une fois le bloc obtenu, il faudra principalement gérer les champs suivants : mnt-routes: (pour gérer les routes auprès du RIPE) et mnt-domains: (pour gérer les reverses DNS).
Мой нод что-то блокирует. Что это? Там был указан ip адрес. Я вывел информацию о нем но в ней не могу разобраться помог
% Note: this output has been filtered.
% To receive output for a database update, use the «-B» flag.
% Information related to ‘0.0.0.0 — 255.255.255.255’
inetnum: 0.0.0.0 — 255.255.255.255
netname: IANA-BLK
descr: The whole IPv4 address space
country: EU # Country is really world wide
org: ORG-IANA1-RIPE
admin-c: IANA1-RIPE
tech-c: IANA1-RIPE
status: ALLOCATED UNSPECIFIED
remarks: The country is really worldwide.
remarks: This address space is assigned at various other places in
remarks: the world and might therefore not be in the RIPE database.
mnt-by: RIPE-NCC-HM-MNT
mnt-lower: RIPE-NCC-HM-MNT
mnt-routes: RIPE-NCC-RPSL-MNT
source: RIPE # Filtered