lunes, 30 de enero de 2017

3 recomendaciones al construir el registro SOA en DNS

Hola, 
  En el presente artículo solo quiero mencionar 3 consejos que al parecer son difíciles de conseguir en Internet pero que son importantes..., hay MUCHOS otros consejos que se pueden dar, repito, voy a mencionar los que quizás no son tan conocidos y a su vez pueden traer problemas operacionales.

Recordando el fomato del registro SOA:
  Un pequeño ejemplo de un registro SOA sería (tomado de una instalación de Bind):
@ IN SOA localhost. root.localhost. (
     1 ; Serial
604800 ; Refresh
 86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL

   De manera muy breve y explicándolo de manera muy entendible: 
El serial: se debe incrementar con cada modificación de la zona. Recordemos que este valor será revisado por los servidores DNS secundarios para identificar si existe algún cambio en la zona
Refresh: Cada cuando tiempo el servidor DNS secundario debe ir al servidor primario y revisar si hubo cambios (¿el valor de Serial es mayor? 
Retry: En caso de que el servidor secundario intentó comunicarse al primario y NO pudo (por la razón que fuese), cada cuanto lo vuelvo a intentar
Expire: Supongamos que el servidor secundario tiene N cantidad de tiempo "N=Expire" sin haber contactado al primario debería dejar de responder. Esto sale del principio que hace mucho que el secundario no contacta al servidor primario y la información que tenga ya puede haber cambiado, el servidor DNS secundario prefiere no dar respuesta que dar información errónea y/o desactualizada. Es decir, el servidor DEJA DE RESPONDER A LA ZONA
Negative Cache TTL: Hace referencia a cachear respuestas DNS negativas...., por ejemplo NXDOMAIN
Revisando lo anterior, nótese que los valores son casi exclusivamente utilizados por los servidores DNS Secundarios que desean hacer zone-transfer.

Consejo 1:
  El Serial nunca debería ser 0. El RFC 2136 indica en la sección 7: "Design, Implementation, Operation, and Protocol Notes". 
  7.11. A zone's SOA SERIAL should never be set to zero (0) due to
   interoperability" ...............

Consejo 2: 
  El valor de Retry no debería ser mayor a Refresh. La razón es bastante lógica, es casi como no tener valor de Retry.., primero ocurre el refresh. Adicionalmente Retry significa contactar el servidor primario para hacer el zone transfer SI NO se pudo contactar antes, con el Retry se buscar mantener la zona actualizada. RFC 1912 indica: ...... "Retry: If a secondary was unable to contact the primary at the
          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval."

Consejo 3:
   El Expire no debe ser menor al Refresh. Similar al consejo 2 pero incluso este lo considero más importante. Si yo tengo un Expire menor que el Refresh significa que el servidor secundario va a dejar de responder la zona antes de que un intento de actualización (Refresh). Obviamente esto no es lo que se quiere. En el RFC 1912 se lee: "Expire: How long a secondary will still treat its copy of the zone
          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals"

Referencias:
- Libro: Cookbook for IPv6 Renumbering in SOHO and
Backbone Networks "https://hal.inria.fr/inria-00000888/file/D3.6.1.pdf"  página 50 indica:  "retry should be smaller than refresh"
- Guia: "Check Point™ Meta IP User’s Guide" pagina 114 indica: "Slave Refresh must be lower than Slave Data Expire and Zone Default TTL"
- Sobre el serial no debería ser 0:  https://mxtoolbox.com/problem/dns/dns-soa-serial-number-format y https://www.digitalocean.com/community/questions/soa-serial-number-format-is-invalid  (sin embargo algunos software de DNS lo aceptan)

The best Buy vps bitcoin from eldernode.com
Where to order pain Relief without prescription
you can buy bitcoin vps from eldernode

Host your website on the fastest servers in Chicago, USA. Hundreds of features you need. Chicago Shared Hosting Easy On-boarding & Simple Website Transfer to our Platform
카지노사이트

domingo, 1 de enero de 2017

Como la navidad puede dañar una red (experiencia real, BTW adoro la navidad)

Hola,
  En este oportunidad voy a contar una experiencia que tuve unos años atrás. Creo que esta vivencia me vino a la cabeza luego de enterarme del Arbol de Navidad controlado por IPv6 [1]

Introducción:
  Alrededor del año 2011 estuve trabajando en una oficina donde ese mismo año se había instalado una red LAN la cual mediante un pequeño enlace DSL llegaba al core de la red de la organización y además se conectaba a Internet.

Sobre el comportamiento general de la red
  Transcurrían los meses desde Junio a Diciembre y la red funcionaba perfectamente, los usuarios satisfechos con el rendimiento, velocidad, aplicaciones entre otros.

Sobre la topología:
  La oficina (ramal) se conectaba mediante un enlace DSL propio (utilizando los mismos pares de cobre de unas lineas telefónicas del edificio), los modems DSL tenían un puerto UTP el cual conectábamos a un LAN Switch Cisco moderno. Como comentario adicional, también manejábamos algunas VLANs para algunos servicios (VoIP).
  La oficina contaba con una cámara de seguridad HD la cual transmitía a un servidor central ubicado en el core de la red (no en la misma oficina).

_______       __________       __________
|Oficina | ---- Enlace DSL   | ---- | Core Office   |
|_____|       |_________ |      |__________|




La llegada de la navidad
  Al igual que en la mayoría de las oficinas y hogares, en la oficina se decidió colocar su respectivo árbol de navidad en la entrada, justo en la puerta principal.
  El árbol fue adornado con sus respectivos ornamentos navideños tales como: bambalinas, micro arbolitos, casitas, cascanueces, estrellas y por supuesto sus luces a lo largo del árbol que titilaban constantemente.


¿Qué ocurrió y como la navidad "dañó" la red?
  Las cámaras mencionabas anteriormente se encontraban apuntando hacia la entrada de la oficina y al igual que muchas otras cámaras y sistemas de CCTV solo transmitían los cambios de la imagen (o lo que es mismo cuando había algún movimiento) al servidor central, es decir, si no habían cambios de pixels en donde apuntaba la cámara, el consumo de ancho de banda era mínimo o casi nulo. Favor recordar que el receptor de la imagen era un servidor central ubicado al otro extremo del enlace DSL y no propiamente en la oficina donde se instaló el árbol.

Para finalizar:
  Entendiendo que un enlace DSL no es de muy alta velocidad y las cámaras son HD el problema puntualmente fue que colocaron el árbol de navidad con sus luces intermitentes junto a la entrada de la oficina, por ende la cámara alcanzaba el mismo haciendo que tuviese que transmitir constantemente al servidor central los cambios de la imagen, es decir, cualquier movimiento en el árbol tal como las luces intermitentes!.

Saludos,

[1] http://ipv6tree.bitnet.be/
[2] Imagen tomada de: http://www.publicdomainpictures.net/pictures/60000/velka/christmas-tree-by-the-fire-place.jpg




BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...