Revisado para uso do AFRINIC por: Adiel Akplogan
ID do documento: afsup-dbref200501-Draft
Data: 20 janeiro 2005
Este documento descreve a funcionalidade do banco de dados AFRINIC que usa a linguagem de especificação de política de roteamento (RPSL) [1] para representar todos os objetos do banco de dados. Embora este documento tenda a ser independente, o leitor é incentivado a ler o RPSL [ 1 ] e RPSS [ 2 ] especificações para informações mais detalhadas, exemplos de uso e definições. Para um tutorial sobre RPSL, o leitor deve ler o documento de aplicativos RPSL [ 3 ]
Introdução 1.0 Consultas no banco de dados AFRINIC 1.1 Consultas usando chaves primárias e de pesquisa 1.2 Pesquisas de endereço IP 1.2.1 Pesquisa padrão para intervalos de IP no banco de dados AFRINIC 1.2.2 Consultas mais e menos específicas 1.3 Consultas inversas 1.4 Obtendo todos os membros dos objetos definidos 1.5 Pesquisas mais / menos específicas para domínios in-addr.arpa e ip6.arpa 1.6 Mecanismo de referência para domínios 1.7 Controle de acesso para consultas 1.8 Outros recursos do servidor 2.0 Atualizações no banco de dados AFRINIC 2.1 Formato de uma mensagem de atualização 2.2 Criando, modificando e excluindo um objeto 2.2.1 Processamento de objetos 2.2.2 Criando um novo objeto 2.2.3 Modificando um objeto existente 2.2.4 Excluindo um objeto 2.3 Atualizações por email 2.3.1 Suporte MIME 2.3.2 Suporte a PGP 2.3.3 Processamento de linha de assunto 2.4 Atualizações usando o utilitário networkupdate 2.5 Agradecimentos e notificações 2.5.1 Agradecimentos Notificações 2.5.2 2.6 Proteção de dados 2.6.1 Modelo de autorização 2.6.2 Proteção de objetos individuais 2.6.3 Proteção do espaço do objeto aut-num 2.6.4 Proteção do espaço de endereço 2.6.5 Proteção de objetos com nomes hierárquicos 2.6.6 Proteção do espaço de objeto do domínio 2.6.7 Protegendo a associação de um conjunto [**] 3.0 Espelhamento do banco de dados AFRINIC Apêndices
Convenções usadas neste documento
Dentro deste documento, as seguintes convenções são usadas:
indica um espaço reservado ou especificação de sintaxe [opção] indica um texto opcional ou argumento de comando.
Observe que nos modelos de objeto os colchetes "[]" são usados para especificar o tipo de um atributo. "attribute:" indica um atributo.
O banco de dados de gerenciamento de rede AFRINIC contém informações sobre alocações e atribuições de espaço de endereço IP. O registro de roteamento na região AFRINIC será executado neste momento pelo RIPE NCC. Esse banco de dados não contém nenhuma informação sobre o nome de domínio. por favor veja o IANA Banco de dados de ccTLDs para obter uma lista completa dos administradores de ccTLDs.
As informações no banco de dados do AFRINIC estão disponíveis ao público para fins de operação da Internet, mas estão sob direitos autorais. Por favor, veja Apêndice A3 "Informações sobre direitos autorais".
A frase "AFRINIC Database" é frequentemente usada para se referir ao software da interface, e não às informações armazenadas no banco de dados. Em situações ambíguas, este manual de referência deixará claro o que está sendo discutido.
Este documento descreve a funcionalidade do banco de dados AFRINIC (com base na versão 3.0 do RIPE NCC WHOIS) Esta versão usa o RPSL (Routing Policy Specification Language) [1] Ele também integra o RPSS (Routing Policy System Security) [2] para fornecer mecanismos de autorização para permitir um nível mais alto de segurança para o registro de roteamento. Observe que essa última funcionalidade ainda não foi usada pelo AFRINIC.
Este documento é independente. No entanto, ele não contém exemplos de uso e ilustrações de princípios e conceitos relacionados à funcionalidade e implementação do Banco de Dados AFRINIC. O "Manual do Usuário do Banco de Dados AFRINIC"[5] e "Manual de Operações do Banco de Dados AFRINIC" [5] preencherá essa lacuna e fornecerá exemplos e informações detalhadas sobre como interagir com o banco de dados do AFRINIC e como configurar e executar o software do servidor do banco de dados do AFRINIC. O leitor também é incentivado a ler o RPSL [1] e RPSS [2] especificações para informações mais detalhadas, exemplos de uso e definições. Para um tutorial sobre RPSL, o leitor deve ler o documento de aplicativos RPSL [3].
Esta seção descreve a funcionalidade fornecida no banco de dados AFRINIC para permitir que os usuários recuperem objetos do banco de dados. A consulta ao banco de dados é feita usando um cliente que usa o Whois protocolo [12] para consultar e obter as respostas.
Este banco de dados incorporado mecanismo para permitir o whois servidor para rastrear automaticamente as respostas da consulta e limitar a recuperação de informações de contato do banco de dados AFRINIC também é descrito nesta seção. A intenção é limitar os usos não operacionais dos dados (como publicidade), permitindo ao mesmo tempo os usos operacionais da base de dados.
Há um conjunto de regras gerais sobre as respostas do servidor:
O formato geral de uma consulta é:
[-query_flags [argumento de consulta]]
As consultas normais são executadas usando chaves primárias e de pesquisa como argumento para uma consulta. Essas consultas são apresentadas em tabela 1 . Por favor, consulte o documento "Tipos de objetos no banco de dados AFRINIC" para definição de chaves primárias e de pesquisa para uma classe.
Provavelmente, o serviço mais importante fornecido pelo banco de dados AFRINIC é fornecer informações sobre redes IP na Internet. Esta informação é armazenada no banco de dados na forma de inetnum.
O inetnum e o inet6num armazenam informações sobre intervalos de endereços IP.
Para IPv4, o prefixo é um número inteiro de 32 bits gravado em notação quadrangular pontilhada e com o valor do endereço IP mais baixo do intervalo. O comprimento do prefixo é um número inteiro no intervalo de 0 a 32 (por exemplo, 193.0.0.0/22 especifica o intervalo de 1024 IPv4 endereços começando com e incluindo 193.0.0.0).
Os objetos inetnum representam um IPv4 espaço de endereço na notação de intervalo em que o intervalo é explicitamente especificado como dois números inteiros de 32 bits escritos em notação quadrangular pontilhada separados por um traço ("-") (por exemplo, 93.0.0.0-193.0.3.255, que especifica o mesmo intervalo acima).
Ao lidar com IPv6 intervalos de endereços, apenas o padrão IPv6 notação de prefixo é permitida (o comprimento do prefixo deve estar no intervalo de 0 a 128 e o prefixo é um número inteiro de 128 bits, gravado em grupos hexadecimais de 2 bytes, separados por dois pontos e com o possível uso de notação abreviada para sequências de 0s consecutivas).
Ao consultar o banco de dados para obter informações sobre um intervalo de endereços IP, o usuário pode usar como chaves de pesquisa as seguintes notações de intervalo:
Esses tipos de consultas são apresentados em tabela 2 . O restante desta seção descreve como um usuário pode solicitar que tipos diferentes de informações sejam retornados, em relação a um intervalo específico de endereços IP.
Antes de entrar em detalhes, é útil definir três conceitos freqüentemente usados neste tipo de consultas e que são definidos em relação ao intervalo especificado (pelo usuário) de referência:
Quando nenhum sinalizador é especificado e a chave de consulta é enviada para o whois servidor é um intervalo de endereços IP (ou IPv4 or IPv6, expresso como um único endereço IP, dois endereços IP separados por um hífen ("-") ou um intervalo de endereços IP em notação de prefixo), o AFRINIC whois o servidor tentará encontrar uma correspondência exata para esse intervalo.
Se uma correspondência exata for encontrada, ela será retornada. Caso contrário, uma pesquisa para o menor intervalo menos específico é executada e isso é retornado.
Às vezes, a correspondência exata não é a informação desejada. Nesse caso, há um conjunto de sinalizadores que modificam a resposta do whois servidor. Este conjunto de 4 sinalizadores ("-M", "-m", "-L" e "-l") fornece dois tipos genéricos de consultas conhecidas como consultas mais e menos específicas.
Referem-se a consultas acionadas pelo uso dos sinalizadores "-l" e "-L". Essas consultas retornam informações sobre intervalos de endereços IP que contêm totalmente o intervalo fornecido pelo usuário e podem conter mais endereços.
O sinalizador "-L" solicita que o servidor retorne a correspondência exata, se houver, e todos os objetos que contêm informações sobre intervalos de IP que são maiores que o intervalo fornecido pelo usuário e os contêm completamente.
O sinalizador "-l" solicita que o servidor NÃO retorne a correspondência exata, mas apenas o menor dos intervalos de IPs que é maior que o fornecido pelo usuário e que o contém totalmente. Isso geralmente é chamado de intervalo menos específico de um nível.
Referem-se a consultas acionadas pelo uso dos sinalizadores "-m" e "-M". Essas consultas retornam informações sobre intervalos de endereços IP que estão totalmente contidos no intervalo fornecido pelo usuário e contêm menos endereços.
O sinalizador "-M" solicita que, em vez de retornar a correspondência exata, o servidor retorne todos os subintervalos completamente contidos no intervalo fornecido pelo usuário, independentemente do tamanho.
O "-m" é o equivalente mais específico do sinalizador "-l". Ele solicita que, em vez de retornar a correspondência exata, o servidor retorne subintervalos totalmente contidos no intervalo fornecido pelo usuário. Mas, em vez de relatar todos os subintervalos existentes, ele retornará apenas os maiores intervalos contidos no intervalo do usuário. Estes são geralmente chamados de um nível mais específico.
Consultas inversas são executadas em chaves inversas, conforme definido nos modelos de objeto do AFRINIC Database. Para uma lista completa desses modelos, consulte o documento "Tipos de objetos no banco de dados AFRINIC". Ao emitir esse tipo de consulta, o cliente solicita todos os objetos que fazem referência
o objeto com a chave especificada como argumento de consulta a ser retornado pelo banco de dados. Também é possível solicitar uma consulta inversa para vários atributos (por exemplo, descobrir quais objetos fazem referência a um objeto mntner específico por atributos "mnt-by:", "mnt-lower:").
Nesse caso, o sinalizador de consulta deve ser representado por uma lista de atributos separados por vírgula a serem pesquisados. Nenhum espaço em branco é permitido na lista.
Consulte a Tabela 4 para obter uma lista completa de consultas inversas suportadas.
Em RPSL [3] existem duas maneiras pelas quais um objeto pode ser membro de um objeto definido.
O primeiro é listar objetos em um atributo "members:" no objeto set. Esse é o tipo de relacionamento de membro presente em "Representação de políticas de roteamento IP em um registro de roteamento" [4] (por exemplo, atributo "as-list:" em objetos como macro).
A outra maneira de especificar uma relação de associação é através do uso do atributo "member-of:". Este atributo pode ser usado nas classes route, aut-num e inet-rtr. O valor do atributo "membro de:" identifica um objeto definido do qual esse objeto deseja ser membro.
No entanto, especificar membro-of não é suficiente. O objeto do conjunto também deve ter um atributo "mbrs-by-ref:" listando o mantenedor do objeto que deseja ser um membro do conjunto. Ou seja, o proprietário do conjunto deve validar a reivindicação de associação de um objeto com um atributo "member-of:" e faz isso combinando a linha mnt-by do objeto com um dos mantenedores no "mbrs-by- ref: "atributo do objeto definido.
O banco de dados AFRINIC oferece suporte a pesquisas de IP, incluindo a funcionalidade "-x", "-m", "-M", "-l" e "-L" para domínios de delegação reversa. Para solicitar que os domínios de delegação reversa sejam pesquisados, use a sinalização "-d" em seu Whois Consulta de pesquisa de IP.
O mecanismo de referência fornece uma maneira para os administradores de registros de domínio instruirem o whois servidor para responder ao usuário buscando dados do banco de dados de registro de domínio em vez de dados locais. Sua implementação consiste em duas partes diferentes:
Se uma consulta ao whois servidor resulta na recuperação de um objeto local que contém um atributo "refer:", o servidor se conectará ao servidor remoto e emitirá um whois consulta para o nome de domínio solicitado. O que quer que seja retornado é enviado ao usuário. Este mecanismo é desabilitado incluindo o sinalizador "-R" na consulta original.
Esta seção descreve o mecanismo para controlar quantos objetos de banco de dados um determinado whois o cliente pode recuperar do whois servidor. O objetivo é controlar e prevenir o uso abusivo da Base de Dados por meio de consultas sistemáticas a informações de contato potencialmente utilizadas para fins não acordados (por exemplo, spam).
Portanto, o sistema de controle de acesso limita apenas a quantidade de informações de contato (número de objetos de pessoa e função) que podem ser recuperadas em um determinado período de tempo. Não existem limitações no número de outros objetos.
No entanto, é preciso ter em mente que muitas pesquisas de tipos de objetos, além de pessoa e função, também retornam informações de contato por padrão. Para evitar ser bloqueado nesses casos, é recomendável usar o sinalizador de consulta "-r".
Sempre que uma pessoa ou objeto de função é recuperado, um contador é diminuído. Quando chega a zero, a execução da consulta é interrompida e a conexão é encerrada, exibindo uma mensagem de erro para o cliente (consulte "Erros de acesso" em Apêndice A2 "Códigos e mensagens de resposta do banco de dados AFRINIC"), também um contador de excede (negações) é incrementado. O banco de dados pode limitar o número de recusas, após o que o host é permanentemente bloqueado de acesso ao banco de dados AFRINIC. A administração do banco de dados também pode bloquear um cliente manualmente, caso seja descoberto qualquer comportamento abusivo.
O contador se recupera a tempo. O host pode retomar a consulta de informações de contato após a recuperação do contador, para que o host obtenha um limite diferente de zero para contatos na próxima vez. A contabilidade é baseada no endereço IP de um cliente.
O servidor de banco de dados AFRINIC fornece um recurso para clientes proxy (por exemplo, servidores Web executando interfaces cgi para o banco de dados AFRINIC) que permite que a contabilidade seja baseada não no endereço IP do proxy, mas nos clientes que usam esse proxy para consultar o banco de dados do AFRINIC. O sinalizador "-V" suporta esse recurso. Nesse caso, o formato da consulta é o seguinte:
-V ,
onde
é uma tag de cliente que geralmente representa a versão do software que o proxy usa;
é o IPv4 endereço do cliente que consulta o banco de dados usando o proxy.
Observe que o endereço IP do proxy deve ser registrado na lista de controle de acesso do banco de dados AFRINIC. Entre em contato com a Administração de banco de dados do AFRINIC se precisar dessa opção.
O servidor do banco de dados AFRINIC suporta a recuperação de determinadas informações sobre si e os conjuntos de dados servidos usando um sinalizador de consulta "-q".
O sinalizador "-q" aceita argumentos que fazem o servidor responder com informações que não são extraídas dos bancos de dados em que ele serve, mas sim sobre a configuração do sistema. Atualmente, esse sinalizador pode receber dois argumentos:
* versão (uso: versão -q). Exibe informações sobre a versão do software do servidor.
* fontes (uso: fontes -q). Liste todas as fontes disponíveis. O formato da saída é:
: : : -
Onde
- é a string que identifica o banco de dados
(por exemplo AFRINIC); identifica a versão do protocolo de espelhamento.
pode assumir um dos seguintes valores:
- S / N / X - pode espelhar / não pode espelhar / obscurecido
é o menor número de série disponível
é o número de série mais recente disponível.
A semântica a seguir se aplica:
Y: - espelhamento permitido, séries do intervalo primeiro ao último disponíveis.
N: - espelhamento não permitido por razões administrativas. Peça permissão à administração do banco de dados.
N: 0- espelhamento fisicamente impossível (por exemplo, instantâneo estático do último serial).
X: nenhum espelhamento permitido. Uma explicação é dada no .
As tabelas 1 a 6 contêm todos os tipos de consulta suportados pelo banco de dados AFRINIC:
Tabela 1 Consultas usando chaves primárias e de pesquisa
Bandeira |
Chaves de pesquisa |
Efeito |
(IPv4 prefixo de endereço, intervalo ou endereço único) |
Retorna inetnum, roteia objetos com correspondência exata na chave especificada. Se a correspondência exata não existir, os objetos com a menor correspondência menos específica serão retornados. Quando um único endereço é especificado, também é retornado um objeto inet-rtr cujo atributo "ifaddr:" corresponde ao argumento de consulta. |
|
(IPv6 endereço ou IPv6 prefixo) |
Retorna um objeto inet6num com correspondência exata em uma chave especificada. Se a correspondência exata não existir, o objeto com a menor correspondência menos específica será retornado. |
|
Retorna um objeto aut-num cujo atributo "aut-num:" corresponde ao argumento de consulta e um objeto as-block com o intervalo que contém o objeto aut-num, se existir. |
||
- (alcance de separado por "-") |
Retorna um objeto as-block cuja chave primária define um intervalo que corresponde ou contém totalmente o intervalo especificado no argumento de consulta. |
|
Retorna objetos de domínio e inet-rtr cujas chaves primárias correspondem ao argumento de consulta. Para domínios, uma consulta de referência pode ser realizada. Nesse caso, a consulta real é realizada pelo servidor referido e os resultados são transmitidos de forma transparente para o cliente. Veja a seção 2.7 "Mecanismo de referência para domínios" para entender melhor. |
||
Retorna um objeto irt cuja chave primária corresponde ao argumento de consulta. |
||
Retorna todos os objetos person e role cujos atributos "person:" ou "role:" contêm o nome especificado no argumento de consulta. |
||
Retorna um conjunto cuja chave primária corresponde ao argumento de consulta. |
||
Retorna uma pessoa ou objeto de função cujo atributo "nic-hdl:" corresponde ao argumento de consulta. |
||
Retorna um objeto mntner cuja chave primária corresponde ao argumento de consulta. |
Tabela 2 pesquisas de endereço IP
Bandeira |
Chaves de pesquisa |
Efeito |
-eu sou |
ou |
Retorna todos os objetos cujos atributos "admin-c:" correspondem ao argumento de consulta. |
-eu ah |
ou |
Retorna todos os objetos limerick cujo atributo "author-c:" corresponde ao argumento de consulta. |
-eu pn |
ou |
Retorna todos os objetos cujo atributo "admin-c:", "tech-c:", "zone-c:", "author:" ou "cross-nfy:" corresponde ao argumento de consulta. |
-eu ct |
Retorna todos os objetos route e aut-num cujos atributos "cross-mnt:" correspondem ao argumento de consulta. |
|
-eu cn |
ou |
Retorna todos os objetos route e aut-num cujo atributo "cross-nfy:" corresponde ao argumento de consulta. |
-eu eu |
Retorna todos os objetos irt cujo atributo "irt-nfy:" corresponde ao argumento de consulta. |
|
-eu la |
Retorna todos os objetos inet-rtr cujo atributo "local-como:" corresponde ao argumento de consulta. |
|
-eu mi |
Retorna todos os objetos inetnum e inet6num cujo atributo "mnt-irt:" corresponde ao argumento de consulta. |
|
-i senhor |
Retorna todos os objetos definidos (como definido, definido como rota e definido como rtr), cujo atributo "mbrs-by-ref:" corresponde ao argumento de consulta. |
|
-eu amo |
Retorna todos os objetos cujo atributo "membro de:" corresponde ao argumento de consulta e sua reivindicação de associação é validada pelo atributo "mbrs-by-ref:" do conjunto. Ausência do atributo "mbrs-by-ref:" significa que a associação é definida apenas pelo atributo "members:" do conjunto. |
|
-Eu sou b |
Retorna todos os objetos cujo atributo "mnt-by:" corresponde ao argumento de consulta. |
|
-eu ml |
Retorna todos os objetos cujo atributo "mnt-lower:" corresponde ao argumento de consulta. |
|
-eu mn |
Retorna todos os objetos mntner cujo atributo "mnt-nfy:" corresponde ao argumento de consulta. |
|
-eu mu |
Retorna todos os objetos aut-num, inetnum e route cujo atributo "mnt-routes:" corresponde ao argumento de consulta. |
|
-eu não |
Retorna todos os objetos cujo atributo "notify:" corresponde ao argumento de consulta. |
|
-ins |
ou (IPv4/IPv6 endereço) |
Retorna todos os objetos de domínio cujo atributo "nserver:" corresponde ao argumento de consulta. |
-eu ou |
Retorna todos os objetos de rota cujo atributo "origin:" corresponde ao argumento de consulta. |
|
-eu rb |
Retorna todos os objetos mntner cujo atributo "referência por:" corresponde ao argumento de consulta. |
|
-eu rz |
ou (IPv4/IPv6 endereço) |
Retorna todos os objetos inetnum e inet6num cujo atributo "rev-srv:" corresponde ao argumento de consulta. |
-eu sd |
Retorna todos os objetos de domínio cujo atributo "subdomínio:" corresponde ao argumento de consulta. |
|
-eu tc |
ou |
Retorna todos os objetos cujo atributo "tech-c:" corresponde ao argumento de consulta. |
-eu não |
Retorna todos os objetos mntner cujo atributo "atualize para:" corresponde ao argumento de consulta. |
|
-eu zc |
ou |
Retorna todos os objetos cujo atributo "zone-c:" corresponde ao argumento de consulta. |
Tabela 4 Suporte de consulta para ferramentas
Bandeira |
Chaves de pesquisa |
Efeito |
-F |
Produz saída usando notação abreviada para nomes de atributos. Produz respostas mais lentas. |
|
-K |
Solicita que apenas as chaves primárias de um objeto sejam retornadas. As exceções são objetos definidos, onde os atributos "members:" também serão retornados. Este sinalizador não se aplica a objetos de pessoa e função. |
|
-k |
(consulta normal opcional) |
Solicita uma conexão persistente. Após retornar o resultado, a conexão não será encerrada pelo servidor e um cliente pode emitir várias consultas na mesma conexão. Observe que o servidor implementa um protocolo "pare e espere", onde nenhuma próxima consulta pode ser enviada antes de receber uma resposta para a anterior. Use RIPE whois cliente para poder enviar consultas em lote. Exceto a primeira "consulta -k", "-k" sem um argumento fecha a conexão persistente. |
-g |
(solicitação de espelhamento) |
Solicite um fluxo NRTM ao servidor. Veja a seção 4.0 "Espelhamento do banco de dados RIPE" para entender melhor. |
Tabela 5 Consultas diversas
Bandeira | Argumento |
Efeito |
-R |
Desativa o uso do mecanismo de referência para pesquisas de domínio, para que o banco de dados retorne um objeto no banco de dados RIPE com a correspondência exata com o argumento de pesquisa, em vez de fazer uma pesquisa de referência. |
|
-r |
Desativa a recursão para informações de contato após recuperar os objetos que correspondem à chave de pesquisa. |
|
-T |
(lista de tipos de objetos separados por vírgula, nenhum espaço em branco é permitido) |
Restringe os tipos de objetos a serem pesquisados na consulta. |
-a |
Especifica que o servidor deve executar pesquisas em todas as fontes disponíveis. Consulte também a consulta "-q sources". |
|
-s |
(lista de fontes separadas por vírgula, nenhum espaço em branco é permitido) |
Especifica quais fontes e em qual ordem devem ser procuradas ao executar uma consulta. |
Tabela 6 Consultas informativas
Bandeira |
Argumento |
Efeito |
-q |
fontes |
Retorna o conjunto atual de fontes junto com as informações necessárias para o espelhamento. Veja a seção 2.9 "Outros recursos do servidor" para entender melhor. |
-q |
versão |
Exibe a versão atual do servidor. |
-t |
Solicita um modelo para o tipo de objeto especificado. |
|
-V |
Envia informações sobre o cliente para o servidor. |
|
-v |
Solicita um modelo detalhado para o tipo de objeto especificado. |
As seguintes notações são usadas nesta tabela:
significa o nome completo ou abreviado de uma classe específica;
é uma string sem um espaço em branco que geralmente leva o nome do software do cliente.
Por favor, consulte a seção 2.8 "Controle de acesso para consultas" para obter mais informações sobre como usar esse sinalizador para clientes proxy. Outras notações são explicadas na Tabela A1.
Para criar um novo objeto, atualizar um existente ou excluir um objeto do Banco de Dados AFRINIC, uma mensagem de atualização deve ser enviada ao Banco de Dados para processamento. São possíveis dois tipos de envio:
* Atualizações via e-mail, que é a principal interface pública, e on-line;
* Atualizações via interface "networkupdate". Este método é interno e é usado apenas em nós autorizados; normalmente, nós pertencentes à LAN do escritório interno do AFRINIC.
Se enviar a mensagem por email, a mensagem também pode ser uma mensagem codificada em MIME. A atualização normalmente está em texto sem formatação. No primeiro caso, cada parte MIME válida é tratada como uma mensagem separada. A mensagem de atualização pode conter mais de um objeto. Consulte a seção 2.3.1 "Suporte MIME" para entender melhor.
Em uma mensagem de atualização, um objeto deve ser representado textualmente como uma lista de pares atributo-valor. Cada par atributo-valor é gravado em uma linha separada. O nome do atributo começa na coluna 0, seguido pelo caractere ":" e seguido pelo valor do atributo. O atributo, que tem o mesmo nome que a classe do objeto, deve ser especificado primeiro. O valor de um atributo pode ser dividido em várias linhas, com um espaço, uma guia ou um sinal de mais ("+")
caractere como o primeiro caractere das linhas de continuação. O caractere "+" para a continuação da linha permite que os valores dos atributos contenham linhas em branco. Mais espaços podem ser usados opcionalmente após o caractere de continuação para aumentar a legibilidade. A ordem dos pares atributo-valor é significativa. Nenhum atributo vazio (um atributo com valor vazio) é permitido, a menos que o tipo de um valor de atributo seja . A definição do objeto começa com o
atributo de classe e termina com a primeira linha em branco ("\ n \ n"). Nenhuma linha em branco é permitida dentro do objeto.
A definição de um objeto pode conter comentários. Um comentário pode estar em qualquer lugar na definição de um objeto, ele começa no primeiro caractere "#" em uma linha e termina no primeiro caractere de fim de linha. Um comentário não pode começar na coluna 0. Caracteres de espaço em branco podem ser usados para melhorar a legibilidade.
Para mais informações sobre o formato dos objetos, consulte o documento "Objetos e atributos do banco de dados AFRINIC".
Cada parte da mensagem que não é reconhecida como um objeto de banco de dados é ignorada e a mensagem de erro é emitida na confirmação.
Para criar, atualizar ou excluir objetos, uma mensagem contendo os objetos deve ser preparada seguindo os modelos de objetos e enviada ao banco de dados para processamento. Uma mensagem pode conter vários objetos, cada um deles pode exigir operação diferente: criação, modificação ou exclusão.
Como regra geral, a ordem dos objetos na mensagem não é alterada. O banco de dados processa os objetos um por um, portanto, é de responsabilidade do usuário garantir que todas as referências possam ser resolvidas. A única exceção está relacionada ao uso de identificadores de placa de rede "AUTO" para atribuição automática de um valor para o atributo "nic-hdl:" nos objetos de pessoa ou função. Nesses casos, objetos com identificadores de placa de rede "AUTO" são processados antes que qualquer outro objeto que possa fazer referência a eles seja processado.
Durante o processamento de um objeto, o servidor executa as seguintes verificações:
Se todas as verificações foram aprovadas com êxito, o servidor cria o objeto no banco de dados AFRINIC. Se uma dessas etapas falhar, a operação falhará para o objeto. Isso se reflete na mensagem de confirmação e, sob certas condições, nas mensagens de notificação.
Após o banco de dados concluir o processamento da mensagem inteira, uma mensagem de confirmação é composta e enviada ao remetente da atualização original, conforme especificado no campo "Responder para:" ou "De:" na mensagem de atualização, se "Responder para : "não foi especificado.
Também em alguns casos, as mensagens de notificação são enviadas. Consulte a seção Notificações 2.5.2" Para maiores informações.
Se um objeto com as mesmas chaves primárias que o objeto na mensagem de atualização não existir no banco de dados, a operação assumida será a criação do objeto. Para a criação de objetos de pessoa e função, pode-se usar "identificadores de NIC AUTOMÁTICOS", solicitando que o servidor atribua automaticamente um identificador de NIC. Nesse caso, o valor do atributo "nic-hdl:" deve ser:
nic-hdl: AUTO-1 [ ]
Se o (2 a 4 caracteres) forem especificados, então o servidor tentará usá-los para construir o identificador da NIC. Se o forem omitidos, o servidor adivinhará as iniciais do atributo "pessoa:" ou "papel:".
Se um objeto com as mesmas chaves primárias que o objeto na mensagem de atualização já existe no banco de dados, a operação assumida é a modificação do objeto. O servidor compara as versões antiga e nova do objeto e relata um erro de não operação se eles forem idênticos. Ao comparar as versões, os caracteres de espaço em branco não são considerados.
A exclusão do objeto é solicitada adicionando um atributo especial "delete:" ao objeto:
excluir:
A exclusão será aceita apenas se o objeto na mensagem for exatamente igual ao do banco de dados prestes a ser excluído. Ao comparar as versões, os caracteres de espaço em branco não são considerados. Além disso, a operação não poderá ser bem-sucedida se o objeto for referenciado de outros objetos no banco de dados.
Uma mensagem de email contendo uma atualização deve ser enviada para o endereço de email do robô AFRINIC Database: auto-dbm@AFRINIC.net. Após o processamento da mensagem, uma confirmação é enviada de volta ao usuário, contendo informações sobre quais atualizações de objetos foram bem-sucedidas e quais falharam, juntamente com o motivo da falha. Em alguns casos, as mensagens de notificação são enviadas aos usuários relevantes. Consulte a seção 3.5.2 "Notificações" para obter mais informações.
O software de banco de dados suporta MIME. Esse recurso visa principalmente facilitar a assinatura criptográfica da mensagem ao usar agentes de correio que colocam a assinatura em uma parte MIME separada, não incluída no corpo da mensagem.
Também permite a definição de escopos de autorização dentro da mensagem (por exemplo, partes onde senhas diferentes se aplicam) e a assinatura aninhada de mensagens, que pode ser necessária sob algumas condições ao atualizar objetos cuja autorização deve ser derivada de mais de uma parte.
As regras a seguir se aplicam ao enviar atualizações usando o encapsulamento MIME.
R. O software reconhece os seguintes cabeçalhos e as ações apropriadas são tomadas:
Todos os outros tipos de conteúdo são tratados como texto / sem formatação.
B. Cada parte do MIME é tratada como uma mensagem separada com as seguintes implicações:
O banco de dados suporta mensagens assinadas por PGP. As regras a seguir se aplicam ao enviar atualizações usando este esquema de autorização.
Ao usar o encapsulamento MIME, uma parte assinada por PGP de uma mensagem de atualização deve ser enviada usando o tipo composto multipart / assinado. Nesse caso, a primeira parte do corpo contém a mensagem de atualização (que também pode ser uma mensagem encapsulada em MIME) e o segundo corpo contém uma assinatura PGP encapsulada com o tipo discreto MIME do aplicativo / assinatura pgp. Em relação à atribuição de identificador de NIC AUTO, a parte assinada por PGP é tratada como uma mensagem separada. Se uma das assinaturas falhar em uma parte assinada aninhada, a parte inteira será rejeitada.
As três palavras-chave válidas em uma linha de assunto de uma mensagem de atualização são NEW, HELP e HOWTO. Use NEW keyword por si só, se desejar que o banco de dados aceite apenas novos objetos. As palavras-chave HOWTO e HELP podem ser usadas para obter um texto de ajuda que contém informações sobre como consultar e atualizar o banco de dados (nesse caso, o corpo da mensagem é ignorado). Se houver mais de uma palavra-chave ou não-palavra-chave na linha de assunto, toda a linha de assunto será ignorada.
Nenhum encapsulamento MIME é possível ao usar o networkupdate. Nenhuma autenticação PGP é possível ao usar o networkupdate.
O processamento de todos os objetos válidos na mensagem de envio (ou seja, todos os objetos em partes de texto sem formatação, partes MIME suportadas e / ou partes assinadas PGP válidas) é refletido na mensagem de confirmação. Esta mensagem contém informações sobre se a criação, modificação ou exclusão foi bem-sucedida ou não. Quando houver uma parte MIME com um tipo não suportado na mensagem recebida, um aviso será adicionado à confirmação, dizendo que essa parte MIME é ignorada. A mensagem de confirmação é enviada de volta ao endereço de email do remetente ("Responder para:" ou "De:", se o primeiro não estiver especificado).
A mensagem de reconhecimento começa com o cabeçalho da mensagem de atualização original como uma cotação seguida pelos resultados das atualizações executadas para cada objeto válido da mensagem.
O formato de um relatório de operação bem-sucedido é:
ESTÁ BEM: [ ]
onde
pode ser Novo, Atualizar, Excluir, dependendo da operação realizada.
é a classe do objeto que foi processado.
é a chave primária do objeto.
Por exemplo:
Atualização OK: [pessoa] FOO12770-AFRINIC
As atualizações com falha são relatadas como:
FALHOU: [ ]
seguido pelo texto do objeto com uma explicação mais detalhada do que causou a falha.
Há várias razões pelas quais a operação pode falhar para o objeto. Eles são:
Existem três tipos de notificações:
As notificações normais são enviadas:
Quando uma atualização falha em passar nas verificações de autorização, esse objeto na mensagem de atualização é encaminhado para o endereço de email especificado no atributo "atualizar para:" do (s) mantenedor (es) relevante (s).
As notificações cruzadas são enviadas:
O banco de dados AFRINIC fornece mecanismos para controlar quem pode fazer alterações no banco de dados e quais alterações podem ser feitas. A distinção de "quem" vs. "o quê" separa autenticação da autorização.
Partes diferentes do banco de dados requerem diferentes níveis de proteção. Algumas aplicações requerem autenticação com base em criptografia forte. Em outros casos, a criptografia forte pode não ser necessária ou pode não estar disponível legalmente. Por esse motivo, vários métodos de autenticação são suportados pelo servidor.
Os objetos mntner servem como um contêiner para armazenar filtros de autenticação. Uma referência a um mantenedor dentro de outro objeto define a autorização para executar operações no objeto ou em um conjunto de objetos relacionados. Essa referência é fornecida por meio dos atributos "mnt-by:", "mnt-lower:", "mnt-routes:" e "mbrs-by-ref:". O mantenedor contém um ou mais atributos "auth:". Cada atributo "auth:" começa com uma palavra-chave que identifica o método de autenticação seguido pelas informações de autenticação necessárias para aplicar esse método.
Ao enviar uma atualização que exija autorização de um mntner, as informações de autenticação válidas para esse mntner devem ser fornecidas. Métodos diferentes requerem informações de autenticação diferentes, como será mostrado abaixo.
Os métodos de autenticação atualmente suportados incluem o seguinte:
Método / Descrição
NENHUM
Nenhuma verificação de autorização é executada.
MAIL DE*
Esta é uma verificação de autenticação muito fraca e é desencorajada. As informações de autenticação são uma expressão regular sobre caracteres ASCII. O mantenedor é autenticado se o campo "De:" nos cabeçalhos de email do RFC 822 for correspondido por essa expressão regular. Como a falsificação de cabeçalho de correio é bastante fácil, essa é uma forma muito fraca de autenticação.
CRIPTO-PW
Essa é uma forma relativamente fraca de autenticação. As informações de autenticação são uma senha criptografada fixa no formato de criptografia UNIX. O mantenedor é autenticado se a transação contiver a senha de texto não criptografado do mantenedor. Como a senha está em texto não criptografado nas transações, ela pode ser capturada por espionagem. A forma criptografada da senha não é mais exibida na saída de uma consulta, a fim de protegê-la de ataques de adivinhação de senha. As informações de autenticação são fornecidas usando um pseudo atributo "password:". O valor desse atributo é uma senha de texto não criptografado. Pode aparecer em qualquer parte do corpo da mensagem, mas não nos cabeçalhos de mensagens. A continuação de linha não é permitida para este atributo.
MD5-PW
Este esquema é baseado no algoritmo de hash MD5 e fornece autenticação mais forte do que CRYPT-PW. As informações de autenticação armazenadas no banco de dados são uma frase secreta criptografada usando o algoritmo md5-crypt, que é uma concatenação da string "$ 1 $", o salt e a saída hash de 128 bits. Como ele usa um salt de 8 caracteres e uma senha longa quase ilimitada, esse esquema é mais estável contra ataques de dicionário. A forma criptografada da senha é filtrada de whois resultado da consulta para protegê-lo de ataques de cracking. As informações de autenticação são fornecidas usando um pseudo-atributo "senha:". O valor deste atributo é uma frase-senha de texto simples. Ele pode aparecer em qualquer parte do corpo da mensagem, mas não nos cabeçalhos de correio. A continuação de linha não é permitida para este atributo, o atributo e a senha devem caber em uma linha. Se a chave for dividida em várias linhas, isso será tratado como um erro de sintaxe.
PGPKEY
Forma forte de autenticação. As informações de autenticação são uma identidade de assinatura que aponta para um certificado de chave pública, armazenado em um objeto separado. O mantenedor é autenticado se a transação for assinada pela chave privada correspondente. O AFRINIC não garante que uma chave pertença a qualquer entidade específica; não é uma autoridade de certificação. Qualquer pessoa pode fornecer qualquer chave pública com qualquer informação de propriedade ao banco de dados e essas chaves podem ser usadas para proteger outros objetos, verificando se a atualização vem de alguém que conhece a chave secreta correspondente.
* O esquema de autenticação MAIL-FROM não é válido no banco de dados AFRINIC.
2.6.2 Proteção de objetos individuais
Objetos individuais podem ser protegidos com um objeto mntner. O mntner é referenciado pelo atributo "mnt-by:" no objeto. O tipo de atributo é múltiplo, portanto vários mntners podem proteger o objeto. Somente aqueles mntners referenciados pelos atributos "mnt-by:" estão autorizados a modificar ou excluir o objeto. Observe que as verificações de autenticação são OR-ed, portanto, se pelo menos um mntner for autenticado, a operação será autorizada. Isso significa que a proteção do objeto é tão fraca quanto o método de autenticação mais fraco usado nos mntners mencionados pelo objeto. Quando o atributo "mnt-by:" é adicionado a um objeto pela primeira vez (como parte da criação ou modificação de objetos), a operação deve passar nas verificações de autenticação dos mntner (s) referenciados por este atributo.
A proteção do espaço do objeto aut-num é feita usando uma classe como bloco. O mntner que autoriza a criação de objetos as-block ou objetos aut-num mais específicos é especificado pelo atributo "mnt-lower:" do objeto as-block. Quando nenhum atributo "mnt-lower:" é especificado, o atributo "mnt-by:" é usado.
As alocações e atribuições de espaço de endereço são representadas pelos objetos inetnum e inet6num. O atributo "mnt-lower:" é usado para referenciar um mntner que autoriza a criação de objetos inetnum ou inet6num mais específicos. Quando nenhum atributo "mnt-lower:" é especificado, o espaço de endereço não está protegido.
Muitos objetos RPSL não possuem uma hierarquia natural própria, mas permitem nomes hierárquicos. Alguns exemplos são os tipos de objeto como definido e definido como rota. Um conjunto pode ter um nome correspondente a nenhuma hierarquia de nomes, como "AS-Foo" ou um nome hierárquico no formato "AS1: AS-BAR". Quando um nome hierárquico não é usado, a autorização para objetos como as-set e route-set corresponde às regras para objetos individuais descritas na seção 3.6.2 "Proteção de objetos individuais".
Se nomes hierárquicos forem usados, a adição de um objeto deverá ser autorizada pelo objeto cuja chave é nomeada por tudo à esquerda do cólon mais à direita no nome do objeto que está sendo adicionado.
A autorização é determinada primeiro usando a referência do mantenedor "mnt-lower:" ou, se ausente, usando a referência "mnt-by:".
A proteção do espaço do objeto do domínio é feita com o atributo "mnt-lower:". Quando usado no objeto de domínio, esse atributo faz referência ao mntner que autoriza a criação de objetos de domínio diretamente abaixo na árvore de domínio registrada no Banco de Dados AFRINIC. Por exemplo, um objeto de domínio de nível superior (ccTLD) protege a criação dos objetos de domínio de segundo nível, objetos de domínio de terceiro nível, se não houver um objeto de domínio de segundo nível correspondente etc. Observe que o objeto de domínio de nível superior ( ccTLD ou gTLD) não podem ser criados no banco de dados AFRINIC pelos usuários, apenas pelo administrador do banco de dados.
Quando a associação de um conjunto é especificada através do uso do atributo "membro de:", o servidor verifica a validade da associação ao criar ou atualizar um membro do objeto. Este atributo "member-of:" pode ser usado nas classes route, aut-num e inet-rtr. O valor do atributo "membro de:" identifica um objeto definido do qual esse objeto deseja ser membro.
No entanto, especificar "membro de:" não é suficiente. O objeto do conjunto também deve ter um atributo "mbrs-by-ref:" listando o mantenedor do objeto que deseja ser um membro do conjunto. Ou seja, o proprietário do conjunto deve validar a reivindicação de associação de um objeto com um atributo "member-of:" e faz isso combinando a linha mnt-by do objeto com um dos mantenedores no "mbrs-by- ref: "atributo do objeto definido. Se a declaração não for válida no momento em que o servidor criar ou modificar um membro do objeto (rota, número automático ou inet-rtr), a operação falhará. Se o atributo "mbrs-by-ref:" estiver ausente, o conjunto será definido explicitamente pelo atributo "members:".
Espelhamento quase em tempo real (NRTM) é um mecanismo que permite whois servidores, exceto o primário para um determinado banco de dados, para ter uma cópia atualizada de todos os dados no servidor principal, obtendo modificações à medida que são processados pelo servidor principal.
Periodicamente (definido pela configuração, geralmente a cada 15 minutos), o servidor remoto se conecta ao servidor principal e solicita todas as modificações processadas desde a última conexão. Quando todos os dados são recuperados, a conexão é fechada, até a hora de uma nova conexão.
No banco de dados AFRINIC, o servidor NRTM escuta em uma porta diferente da whois porta (43).
O AFRINIC whois O servidor gera um número de seqüência sempre que processa uma atualização no banco de dados. Com o objetivo de gerar esses números de série, o servidor descreve todas as modificações no banco de dados em termos de duas operações atômicas: exclusão e adição.
Ao enviar dados para um servidor espelho, o servidor principal envia uma das duas cadeias (ADD ou DELETE), seguida de dois caracteres de nova linha e o objeto correspondente (o objeto como era antes da exclusão ou o objeto como deveria ser adicionado ou modificado ) Se a sequência "ADD" for seguida por um objeto já existente no banco de dados, essa operação será considerada uma modificação. O espelhamento quase em tempo real é solicitado com o sinalizador "-g". Os argumentos para esse sinalizador são:
-g <fonte>: : -
onde
* é a string que identifica o banco de dados (por exemplo, AFRINIC).
* uma versão do protocolo de espelhamento que o suporta (2 para AFRINIC).
* é o menor número de série solicitado.
* é o número de série mais recente solicitado ou a palavra-chave LAST que informa ao servidor principal para enviar todas as atualizações até a mais recente disponível no momento da consulta. Observe que o servidor nunca produzirá o último objeto processado ou exibirá que ele está disponível para espelhamento. Isso é feito para proteger os servidores secundários caso a última atualização cause corrupção do banco de dados e travamento do servidor.
Um cliente pode solicitar uma conexão persistente incluindo o sinalizador "-k" com uma solicitação de espelhamento (consulta "-g"). Nesse caso, o último argumento é ignorado e os novos objetos são fornecidos pelo servidor assim que são processados. O cliente é responsável por fechar a conexão.
O sinalizador "-q sources" pode ser usado com o servidor de espelhamento para recuperar informações sobre as possibilidades de espelhamento disponíveis. Consulte a seção 2.9 "Outros recursos do servidor" para obter mais detalhes.
Observe que o servidor nunca retorna a série mais recente ao atender a uma solicitação de espelhamento. Portanto, se o serial mais recente causar uma pane no servidor e danificar o banco de dados, ele nunca será propagado para os servidores secundários. A série mais recente também não é exibida com a consulta "-q sources".
No início do fluxo de dados, o servidor principal enviará a seguinte string:
% START Version: NRTM_Protocol_version_ # source first-last
Por exemplo:% START Versão: 2 AFRINIC: 1539595-1539597
Depois que o último dado é enviado ao servidor espelho, o servidor principal envia a string:
% END fonte para sinalizar o fim da transmissão.
Por exemplo:
% AFRÍNICO FINAL