DNS LACNOG

dns@listas.nog.lat

205 discussions

Re: [dns-esp] Consulta DNS.
by Hugo Salgado 03 Oct '17

03 Oct '17

Este script toma archivos de zona en formato "bind" y genera los comandos de nsupdate para enviarlos a otro servidor autoritativo. Podría servirte: http://dotat.at/prog/nsdiff/nsdiff.html Saludos, Hugo On Oct 2, 2017 15:37, "Miguel Angel Amador" <miguel(a)motd.cl> wrote: Estimados listeros... Estoy haciendo una migración de servidores DNS y lo mas critico es conservar los registros en el paso de migración, como es desde una plataforma DDI a Otra..... no es tan sencillo como colocar el nuevo como slave y después promoverlo a master. si no que debo migrar la BD del IPAM, teniendo que validar los dns a manito. Son como 400 zonas y 250.000 registros, por lo que la primera consulta es: Quiero leer el archivo de configuración de la plataforma actual que trabaja sobre bind, y tirar la query contra el servidor nuevo cuando este ok, entonces para no re-inventar la rueda, queria saber si alguien ha utilizado algún programa que parsee el archivo de bind sacando los registros y su tipo y tome ese dato y le mande la query a un servidor especifico, para así validar que estén todos los registros. solo quiero saber si existe o alguien sepa de algo que me pueda servir antes de ponerme a construir el script a mano y la otra consulta, los archivos de bind que mantienen los registros de la zonas los tengo en .db y son de tipo data y no encuentro como leerlos, alguien sabe como pasarlos a TXT? Cualquier tips/ayuda es bienvenida! Atte Miguel Amador _______________________________________________ dns-esp mailing list dns-esp(a)listas.nic.cl https://listas.nic.cl/mailman/listinfo/dns-esp

2 1

[dns-esp] DNS-OARC Live streaming #OARC27 San Jose, CA
by Mauricio Vergara Ereche 29 Sep '17

29 Sep '17

Hola! Por si no lo habían visto... La reunión de DNS-OARC está con streaming live via youtube en este momento. Cada sesión cambia la dirección, por lo que sugiero seguir desde su sitio de Google+: https://plus.google.com/+DnsoarcNetPlus/ Una vez que hayan terminado las charlas, éstas quedaran guardadas en línea en el mismo canal de YouTube: https://www.youtube.com/channel/UCtgW_wIPdA_WBmMKX79JT4g Saludos! -- Mauricio Vergara Ereche Los Angeles, CA http://mave.cero32.cl

1 0

Re: [dns-esp] [lacnog] KSK Roll Pospuesto
by Luciano Minuchin 28 Sep '17

28 Sep '17

En las ultimas reuniones de LACNIC y LACNOG, se hablo sobre esto y comente que muchos no estaban listo para el cambio. No me sorprenden los porcentajes de equipos que no estan actualizados, es mas diria que en la region puede ser incluso mas alto. Me toco la opoctunidad de verificar mcuhos DNS de esta parte del mundo y no estaban prepardos. Deberiamos poder tomar algun plan de accion proactivo para ayudar a los que no saben que acciones tomar o todavia no trabajaron en este tema.. Saludos. Luciano. El 27 de septiembre de 2017, 22:40, Carlos Marcelo Martinez Cagnazzo < carlosm3011(a)gmail.com> escribió: > No tengo mas datos todavia, pero esto recien fue publicado > > https://www.icann.org/news/announcement-2017-09-27-en > > via Newton Mail > <https://cloudmagic.com/k/d/mailapp?ct=pi&cv=9.8.55&pv=11.0&source=email_foo…> > > > _______________________________________________ > LACNOG mailing list > LACNOG(a)lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > >

4 4

[dns-esp] Fwd: Operational message: DNS root zone KSK rollover to occur on October 11, 2017 at 1600 UTC
by Luciano Minuchin 20 Sep '17

20 Sep '17

Importante!!!, deifncion del horario para el cambio en la zona raiz. Saludos. Luciano. ---------- Forwarded message ---------- From: Matt Larson <matt.larson(a)icann.org> Date: 2017-09-20 14:25 GMT-03:00 Subject: Operational message: DNS root zone KSK rollover to occur on October 11, 2017 at 1600 UTC To: "root-dnssec-announce(a)iana.org" <root-dnssec-announce(a)iana.org> The root zone management partners, ICANN and Verisign, are working together to change the DNS root zone's key-signing key (KSK). This process is referred to as "rolling" the root zone KSK. The root zone's apex DNSKEY RRset has been signed with the same KSK, known as KSK-2010, since the root zone was first signed in July, 2010. On October 11, 2017, at approximately 1600 UTC, the root zone will be published with the apex DNSKEY RRset signed for the first time with a new KSK, known as KSK-2017. The root zone apex DNSKEY RRset will be signed with only KSK-2017 going forward. While the specific date of the KSK rollover, October 11, 2017, had been announced previously, the time of 1600 UTC on that day has not been announced until now, which is the primary purpose of this message. The public portion of the root zone KSK is configured as a trust anchor in software performing DNSSEC validation. The configuration of any software performing DNSSEC validation will need to be updated to reference KSK-2017 on or before October 11, 2017, or all DNS responses received by that software will fail DNSSEC validation, resulting ultimately in error messages to end users. In many cases, software performing DNSSEC validation supports "Automated Updates of DNS Security", the protocol defined in RFC 5011 that can automatically update a DNSSEC validator's trust anchor configuration. If the software does not support this protocol, or it is incorrectly implemented or not configured correctly, the trust anchor will need to be updated manually. Anyone operating software performing DNSSEC validation with the root zone KSK configured as a trust anchor must take action on or before October 11, 2017, to confirm that their software is configured with KSK-2017 as a trust anchor and, if not, take the necessary steps to update the configuration. Further information about the root KSK rollover, including information about how to check and update the trust anchor configuration of popular recursive resolver implementations that support DNSSEC validation, is available at https://icann.org/kskroll. For the root zone management partners, Matt Larson VP of Research, ICANN Duane Wessels Distinguished Engineer, Verisign _______________________________________________ root-dnssec-announce mailing list root-dnssec-announce(a)icann.org https://mm.icann.org/mailman/listinfo/root-dnssec-announce

3 2

[dns-esp] Información sobre la rotación de la KSK de la raíz
by Hugo Salgado-Hernández 12 Sep '17

12 Sep '17

Estimad@s, la próxima semana se viene el primer paso (dentro del DNS) de la rotación de la llave KSK de la raíz. Este tema es muy importante para los que mantienen DNS resolvedores, validen o no! Como prometimos, acá dejamos información que esperemos sea clara y completa: http://www.lacnog.org/wg-dns-ksk-rollover/ Espero que les sea de utilidad, y por favor conversemos acá cualquier duda, sugerencia, comentario, etc. Por favor compártanlo en sus comunidades! Saludos y gracias. Hugo

6 7

[dns-esp] Informe de IETF99 - Praga, 17-21 de julio de 2017 en español
by Maria Fernanda Alvarez 12 Sep '17

12 Sep '17

Estimados Sres., Es un gusto saludarlos. Tenemos el agrado de enviarles el Informe de IETF99 - Praga, 17-21 de julio de 2017 en español (adjunto). La traducción fue realizada por LACTLD con la revisión de Hugo Salgado (nic.cl) a quien LACTLD le agradece. El informe también está disponible en nuestra página web: http://www.lactld.org/wp-content/files_mf/ietf2017.pdf Para acceder a la versión en inglés de este informe ira a Highlights de: https://centr.org/ Saludos Cordiales, María Fernanda Alvarez Oficial de Información / Information Officer LACTLD - www.lactld.org <http://www.lactld.org> Casa de Internet de Latinoamérica y el Caribe Rambla Rep. de México 6125 11400 Montevideo-Uruguay +598 2604 22 22

2 1

[dns-esp] Fwd: [lacnog] Webinar Rotación de la KSK de la zona raíz- 9 de agosto
by Hugo Salgado-Hernández 09 Aug '17

09 Aug '17

Todos invitados a este webinar! Sobre todo a participar enviando sus preguntas o comentarios a comunicaciones(a)lacnic.net, para que sean respondidas durante el evento. Saludos, Hugo

1 1

[dns-esp] Fwd: [NCUC-DISCUSS] ICANN seeks consultants for two reviews
by Alejandro Acosta 19 Jul '17

19 Jul '17

-------- Mensaje reenviado -------- Asunto: [NCUC-DISCUSS] ICANN seeks consultants for two reviews Fecha: Sat, 15 Jul 2017 09:44:54 +0200 De: William Drake <william.drake(a)uzh.ch> Para: NCUC-discuss <ncuc-discuss(a)lists.ncuc.org> Hi ICANN needs to do reviews of the SSAC and the RSSAC. I’ve been asked to circulate the CFPs. If anyone is interested and has the relevant expertise please see the below. RSSAC: https://www.icann.org/news/announcement-2017-07-11-en SSAC: https://www.icann.org/news/announcement-2017-07-07-en Cheers Bill *********************************************** William J. Drake International Fellow & Lecturer Media Change & Innovation Division, IPMZ University of Zurich, Switzerland william.drake(a)uzh.ch <mailto:william.drake@uzh.ch> (direct), wjdrake(a)gmail.com <mailto:wjdrake@gmail.com> (lists), www.williamdrake.org <http://www.williamdrake.org> ***********************************************

1 0

[dns-esp] Ayuda con registro PTR
by Alexander 19 Jul '17

19 Jul '17

Hola a todos! Les escribo con el fin de obtener alguna ayuda por parte de ustedes. Se nos está presentando la siguiente situación con un nuevo cliente; ellos nos están solicitando la resolución inversa con una dirección IP de nosotros, ya que la IP la están bloqueando por spam, además porque los logs del servidor de ellos presentan el siguiente error: Jul 18 14:55:07 www postfix/pickup[13415]: B1E439FB6B: uid=33 from=<registro(a)municarrillo.go.cr> Jul 18 14:55:07 www postfix/cleanup[13872]: B1E439FB6B: message-id=<20170718205507.B1E439FB6B(a)www.municarrillo.go.cr> Jul 18 14:55:07 www postfix/qmgr[1799]: B1E439FB6B: from=<registro(a)municarrillo.go.cr>, size=700, nrcpt=1 (queue active) Jul 18 14:55:09 www postfix/smtp[13874]: B1E439FB6B: host mx.grupomicrosistemas.com[66.96.140.68] refused to talk to me: 554 bosimpinc13 bizsmtp Connection rejected. Reverse DNS for 200.5.60.123 does not exist. Jul 18 14:55:10 www postfix/smtp[13874]: B1E439FB6B: to=<info(a)grupomicrosistemas.com>, relay=mx.grupomicrosistemas.com[66.96.140.69]:25, delay=2.9, delays=0.02/0.01/2.8/0, dsn=4.0.0, status=deferred (host mx.grupomicrosistemas.com[66.96.140.69] refused to talk to me: 554 bosimpinc13 bizsmtp Connection rejected. Reverse DNS for 200.5.60.123 does not exist.) Nosotros no poseemos en este momento un servidor autoritativo(Se están realizando los trámites para comprar el hardware), tratando de resolverle de manera temporal, en uno de los servidores recursivos con Bind, configuré una zona reversa de la siguiente manera: *zone "123.60.5.200.in-addr.arpa" {** ** type master;** ** file "/var/lib/bind/200.5.60.123.rev";** ** };* Este es el archivo .rev: *$ttl 38400** **123.60.5.200.in-addr.arpa. IN SOA municarrillo.go.cr. a_cortes.municarrillo.go.cr. (** ** 1500402085** ** 10800** ** 3600** ** 604800** ** 38400 )** **123.60.5.200.in-addr.arpa. IN NS municarrillo.go.cr.** *** A la hora de hacer consultas con el comando dig, me muestra el siguiente resultado: root@DNS2:/var/lib/bind# dig -x 200.5.60.123 @200.5.60.110 *; <<>> DiG 9.10.3-P4-Ubuntu <<>> -x 200.5.60.123 @200.5.60.110** **;; global options: +cmd** **;; Got answer:** **;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39244** **;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1** ** **;; OPT PSEUDOSECTION:** **; EDNS: version: 0, flags:; udp: 4096** **;; QUESTION SECTION:** **;123.60.5.200.in-addr.arpa. IN PTR** ** **;; AUTHORITY SECTION:** **123.60.5.200.in-addr.arpa. 38400 IN SOA municarrillo.go.cr. a_cortes.municarrillo.go.cr. 1500402085 10800 3600 604800 38400** ** **;; Query time: 0 msec** **;; SERVER: 200.5.60.110#53(200.5.60.110)** **;; WHEN: Tue Jul 18 16:07:46 CST 2017** **;; MSG SIZE rcvd: 117* Hay algo malo en la configuración? Hay otro método que me permita resolver este problema mientras implementamos el autoritativo? Quedo atento a sus respuestas y muchas gracias de antemano!!! --

3 4

[dns-esp] Mejor Practica para DNS en la nube
by Miguel Angel Amador 11 Jul '17

11 Jul '17

Estimados Alguien tendra una guia de las mejoras practicas por el lado de seguridad... para colocar DNS 's en la nube? ... por aca un cliente interno se esta llevando el dns a cloudflare, dejando el master en la nube, aparte de perder la sincronizacion con el dns interno (entrar a configurar en ambientes separados un registro), siento que deberían tener el master (visible solo a los slave, pero onpremise) y los slave en la nube, para su replicacion. Pero necesito algún estudio que avale lo que pienso. Se agradece cualquier documento que aporte alguna directriz al respecto. Saludos Miguel Amador L.

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

DNS LACNOG