[LACNIC/Politicas] LACVI-01 Lame Delegation

Thu Feb 19 19:51:13 BRT 2004

Marcelo,

Vou tentar explicar o que neste contexto estamos chamando de
delegações sintéticas, e quando elas ocorrem. Desculpem o tamanho da
mensagem.

O sistema de controle de blocos atualmente permite as seguintes
operações de delegação em função do tamanho da alocação direta:

Prefix len (pl) 	Delegações			
      pl <= /16		n * x.x.in-addr.arpa.		n = 2 ^ (16-pl)
/16 < pl <= /24 	n * x.x.x.in-addr.arpa.		n = 2 ^ (24-pl)

Nas situações em que pl é igual ao boundary superior, ou seja, 16 e 24
ocorre uma única delegação e o ato de verificação e controle de
lame-delegation é em relação a uma única zona.

Nas situações em que pl é diferente dos boundaries podem ocorrer
situações de múltiplas zonas mas assim mesmo estas múltiplas zonas
sempre estarão delegadas aos mesmos servidores.

É importante compreender que o sistema de delegação DNS atual trata as
delegações como uma lista de propriedades de um bloco, ou seja, um
bloco alocado fora de um destes boundaries pode tratar a delegação DNS
como sendo total ao bloco ou pode faze-la da forma que lhe for mais
adequada em "prefixos" maiores. 

A resposta as perguntas na mensagem inicial a lista depende na verdade
do entendimento da forma que as delegações podem ser feitas como
reportado acima. Em situações de uma delegação total o que irá ocorrer
é uma remoção total. Nos casos de reassignment de prefixos <= 24 a
delegação é sempre uma prerrogativa do detentor deste sub-bloco e não
irá de forma alguma impactar o restante das delegações no bloco "pai".

Vou exemplificar: Este é um caso real aonde um bloco possui várias
delegações. Os marcados com "*" representam o bloco asignado ou as
reasignações, os outros são as delegações.

*200.49.64/19 (7 delegações DNS)
	200.49.64/21
	200.49.72/23
	200.49.74/24
		*200.49.75/24 (0 delegações DNS)
	200.49.76/22
		*200.49.80/23 (0 delegações DNS)
	200.49.82/23
	200.49.84/23
		*200.49.86/23 (1 delegação DNS)
			200.49.86/23
	200.49.88/21

A delegação para o espaço 200.49.64/21 é na realidade a delegação de 8
zonas [64-71].40.200.in-addr.arpa.

O sistema atual quando da verificação desta delegação efetua a
verificação de 8 zonas por servidor e caso encontre alguma com
problema, agrega estes problemas e reporta o mais significativo no
whois. Nestes casos o que a política propõe é que todas estas
delegações ([64-71].40...) sejam removidas, obviamente na situação
limite após todos os avisos.

Acredito que o principal impacto possa ocorrer com os operadores que
tenha asignados blocos com prefixo /17 e tenham efetuado uma única
delegação para todo o bloco. Neste caso uma única zona com problema
poderá acarretar a remoção de todas as outras (127). No caso aonde
esta delegação é no fundo efetuada para uma única entidade o controle
disto é simples. No caso em que isto no fundo é controlado por várias
entidades o sistema tem a flexibilidade de permitir os reassignments ou
as delegações em prefixos mais específicos para contornar o problema
administrativo.

Mesmo os casos como o reportado pelo Cristiam, em que parte da
delegação é efetuada para os servidores do ISP, mas no fundo estes são
configurados como secundários de um "hidem" master do cliente podem
ser isolados com a delegação de um sub-bloco específico ou o
reasignment.

Situações de configuração conforme descrito no BCP20, caso tenham sido
feitas da forma correta pelo ISP não causam lame-delegation ao menos
na delegação RIR-ISP. Ela pode ocorrer nas sub-zonas mas isto não
impacta a delegação do todo e portanto não é controlada.

Vou efetuar um levantamento de todos os prefixos entre 17 e 20 que
possuam delegações para todo o bloco e vou classifica-los em com e sem
lame-delegation e enviar a lista para subsídio a discussão.

Saudações,
Frederico Neves
CTO Lacnic

On Wed, Feb 18, 2004 at 05:57:19PM +0100, marcelo bagnulo wrote:
> > Algunos de los cuestionamientos fueron
> >
> > *Que pasa con los bloques reasignados a clientes de los ISP y estos
> > segmentos son operados por servidores DNS administrados por
> > clientes? Como
> > atiende la política los segmentos reasignados?
> >
> > * Si un bloque /24 presentara problemas de Lame Delegation y este forma
> > parte de la asignación de un bloque mayor (/20, /19, /16, etc.) de una
> > organización, como afecta el segmento completo /20, /19, /16, etc?
> >
> > SE HACE UN LLAMADO PRINCIPALMENTE A OPERADORES DE REDES QUE REVISEN ESTA
> > POLITICA Y GENEREN COMENTARIOS EN ESTA LISTA SOBRE LOS IMPACTOS DE ESTOS
> > CRITERIOS EN SUS OPERACIONES.
> 
> 
> Yo no soy un operador de red, pero, en cualquier caso, la discusion en Cuba
> me parecio muy interesante.
> Recuerdo que el problema no era todo lo evidente que parecia a primera vista
> y recuerdo que Frederico menciono algunos problemas con los registros
> sinteticos generados automaticamente. ¿seria posible que alguien (Frederico
> tal vez?) explicara cual es el problema mas detalladamente?, capaz que si
> hay un mayor entendimiento de las dificultades podemos avanzar un poco mas
> en esto...
> 
> Saludos, marcelo
> 
> 
> >
> >
> > *******************
> >
> > During the meeting held the past November in Havana, Cuba, the following
> > proposal for the Lame Delegation policy within the region covered
> > by LACNIC
> > was submitted.
> >
> > Proposal
> > http://lacnic.net/lacnic-V-lame-delegation-en.pdf
> >
> > Presentation at the Public Forum
> > http://lacnic.net/en/des-pol.html
> >
> > This policy is being implemented partially by LACNIC staff, who
> > monitor DNS
> > servers that present Lame Delegation problems and notify the responsible
> > contacts for the solution of the problem. No corrective action is
> > implemented.
> >
> > Since this practice began, the percentage DNS servers with Lame
> > Delegation
> > has decreased from 35% to 24%. This was achieved over a period of six
> > months from the moment the notifications began. Even so, almost
> > one fourth
> > of the DNS servers that perform inverse resolution of IP address blocks
> > assigned within the region covered by LACNIC have this problem. For this
> > reason a policy is necessary.
> >
> > For more details please visit
> > http://lacnic.net/en/lame_delegation.html
> > http://lacnic.net/en/lameness.html
> >
> > As the document of the proposal shows, the process, that as of now
> > concludes with the notification, would include a stage of ELIMINATION of
> > DNS servers with Lame Delegations from the registry on the part of LACNIC.
> >
> > The proposal did not achieve consensus at the Public Forum and was not
> > ratified, because some network operators commented that they
> > consider this
> > policy may affect their operations if it is not well defined.
> >
> > Among of the doubts that arose were:
> >
> > What will happen with the blocks reallocated to ISP clients and these
> > segments are operated by DNS servers administered by clients? How
> > does the
> > policy consider reallocated segments?
> >
> > If a /24 block presents Lame Delegation problems and is part of an
> > organization's allocation of a larger block (/20, /19, 16, etc.),
> > how does
> > it affect the full 20, /19, 16, etc. block?
> >
> > WE REQUEST THE INTERNET COMMUNITY, PARTICULARLY NETWORK OPERATORS, TO
> > REVIEW THIS POLICY AND GENERATE COMMENTS ON THIS LIST RELATING TO THE
> > IMPACT OF THESE CRITERIA ON THEIR OPERATIONS.
> >
> > *****************************
> >
> > Durante a reunião de  Havana, Cuba, em Novembro passado, foi
> > apresentada a
> > seguinte proposta de política de Lame Delegation na região de LACNIC.
> >
> > Proposta
> > http://lacnic.net/lacnic-V-lame-delegation-pt.pdf
> >
> > Apresentação no Fórum Público
> > http://lacnic.net/pt/des-pol.html
> >
> > Esta política está sendo executada parcialmente pela equipe de LACNIC ao
> > monitorar servidores DNS que apresentam problemas de Lame Delegations e
> > notificando aos contatos responsáveis para a solução do problema sem
> > realizar nenhuma ação corretiva do problema.
> >
> > Desde que se iniciou esta prática, diminui-se a porcentagem de servidores
> > DNS com Lame Delegations de um 35% a um 24%. Isto faz 6 meses desde que
> > iniciaram as notificações. Mesmo assim, existe quase 1/4 de
> > servidores DNS
> > que realizam a resolução inversa dos blocos de direção IP
> > designados para a
> > região de LACNIC com este problema. Razão pela qual faz-se necessária a
> > existência de uma política.
> >
> > Maiores detalhes podem ser encontrados em:
> > http://lacnic.net/pt/lame_delegation.html
> > http://lacnic.net/pt/lameness.html
> >
> > Tal como se vê no documento da proposta, o atual processo termina com a
> > notificação, deve ser incluso agora uma etapa de ELIMINAÇÃO do
> > registro dos
> > servidores DNS com problemas de Lame Delegation por parte de LACNIC.
> >
> > A proposta não obteve consenso pelo Fórum Público e não foi ratificada,
> > pois comentários de operadores de redes demonstraram que esta
> > política, uma
> > vez não sendo muito bem definida, poderia afetar suas operações.
> >
> > Alguns dos questionamentos foram:
> >
> > O que acontecem com os blocos re-alocados a clientes ISP e estes
> > segmentos
> > são operados por servidores DNS administrados por clientes? Como
> > a política
> > atenderia aos clientes re-alocados?
> >
> > Se um bloco /24 apresenta problemas de Lame Delegation e este forma parte
> > da alocação de um bloco maior (/20, /19, /16, etc) de uma
> > organização, como
> > afetaria o seguimento completo /20, /19, /16, etc?
> >
> > HÁ UMA CHAMADO FOCADO EM OPERADORES DE REDES PARA QUE REVISEM
> > ESTA POLÍTICA
> > E ENVIEM COMENTÁRIOS A ESTA LISTA SOBRE OS IMPACTOS DESTES CRITÉRIOS EM
> > SUAS OPERAÇÕES
> >
> >
> > German Valdez
> > LACNIC