DNS LACNOG

dns@listas.nog.lat

205 discussions

[dns-esp] RDDS y EBERO
by Rogerio Mariano 21 Jun '17

21 Jun '17

Hola amigos, Alguien en la lista me podría indicar dónde encuentro buenos documentos explicativos sobre la implantación y el uso RDDS y EBERO. He encontrado este link: Https://www.icann.org/resources/pages/ebero-2013-04-02-en Pero me gustaría tener algo más empirico. PS: Es para auxiliar en un estudio. Saludos, Rogerio Mariano.

2 1

[dns-esp] Reunión WG durante LACNIC27
by Hugo Salgado-Hernández 16 Jun '17

16 Jun '17

Estimados colegas. Quería invitar a los que estarán en el evento LACNIC 27 de fines de mes en Foz do Iguaçu, para que hagamos una pequeña reunión del WG DNS. Es solo para contarles de algunos proyectos que tenemos planeados para el futuro, conversar si hay planes o inquietudes para preparar el encuentro LACNOG de septiembre, y por supuesto cualquier tema DNS que sientan relevante para el WG! Fecha: Lunes 22 de mayo (segunda-feira) Hora: 16:30 a 17:00 horas (30 minutos) Lugar: Sala Iguazu VI, Hotel Bourbon Cataratas. Si alguien quiere reservar algunos minutos para tocar algún tema en particular, escríbame por interno y lo agregamos a la agenda. Espero verlos por allá! Saludos, Hugo

1 1

[dns-esp] consulta sobre opciones para bind
by Miguel Angel Amador 15 Jun '17

15 Jun '17

Estimados Recurro a esta lista para saber si alguien me puede guiar, existe alguna opcion en bind, para una configuracion de dns recursivo, que hace forward de las consultas a otro dns. que haga lo siguiente: - bajar el tiempo de espera de respuesta desde el dns al cual hace forward, para matar la query antes del tiempo de espera por defecto. (bajar el timeout) - manejar el maximo numero de querys que puede responder el servicio de dns. Tuve un incidente donde la VIP de un servidor dns se colapso y no contesto mas consultas, pero a traves de otras ip's configuradas en la interfaz si respondia, esto debido a tiempos altos en la respuesta desde los resolver a los cuales hacia forwarding. quedo atento.

4 3

[dns-esp] Llamado a presentación de Trabajos: DNS-OARC 27, San Jose, CA 29-30 Sep 2017
by Mauricio Vergara Ereche 27 May '17

27 May '17

** ENGLISH BELOW ** La versión 27 del Workshop DNS-OARC se llevará a cabo en San Jose, California, Estados Unidos durante los días Viernes 29 y Sábado 30 de Septiembre del 2017, previo al NANOG 71. El comité de programa hace un llamado a presentar propuestas de trabajos. Todos los temas relacionados al DNS son bienvenidos. Si usted es un miembro de DNS-OARC y tiene un contenido sensible que le gustaría presentar en la sesión sólo para miembros, habrá un tiempo especial para ello la mañana del 29 de Septiembre. Además habrá un tiempo asignado para presentaciones cortas (lighting talks) de unos 5-10 minutos el Sábado 30 de Septiembre, las cuales serán aceptadas durante el día Viernes 29. Hitos del Workshop: 26 de Mayo 2017, Llamado a presentación de trabajos y apertura de postulaciones 28 de Julio 2017, Fecha final de envío de propuestas 11 de Agosto 2017, Propuesta de Programa (Agenda) publicada 01 de Septiembre 2017, Programa final publicado 15 de Septiembre 2017, Fecha final para envío de material de presentaciones (slides) Detalles sobre la presentación de los resúmenes de trabajos (abstracts) pueden verse en: https://indico.dns-oarc.net/event/27/call-for-abstracts/ Las presentaciones del workshop serán organizadas por temas comunes, dependiendo de los temas y el tiempo de cada ponencia. Habrán espacios de 30 y 15 minutos para realizar las presentaciones. Por lo que se agradece indicar su preferencia al momento de postular. Para asegurar que el Comité de Programa realice una evaluación objetiva de la propuesta y asegurar la calidad del Taller, las postulaciones DEBEN incluir un set de slides. Durante el período inicial de postulación, borradores (o drafts) del material a presentar estará permitido. Si tiene dudas o consultas, puede contactar directamente al Comité de Programa en: https://www.dns-oarc.net/oarc/programme o via correo <submissions(a)dns-oarc.net> DNS-OARC depende de los auspicios para financiar sus talleres y eventos sociales asociados. Por favor, contacte a <sponsor(a)dns-oarc.net> si su organización está interesada en ofrecer auspicio. (Notar que DNS-OARC es una organización sin fines de lucro, por lo que no está en posición de pagar costes de viaje, viáticos, comisiones o tiempo de los expositores) *** ENGLISH VERSION *** [with apologies to those who see this on multiple lists] Call For Presentations The DNS-OARC 27th Workshop will take place in San Jose, CA, USA on September 29th and 30th 2017, the Friday and Saturday preceding NANOG 71. The Workshop's Program Committee is now requesting proposals for presentations. All DNS-related subjects are welcome. If you are an OARC member, and have a sensitive topic you would like to present for members-only, we can accommodate those talks during the Members Only session on the morning of September 29th. A timeslot will also be available for lightning talks (5-10 minutes) on Saturday September 30th, for which submissions will be accepted during Friday 29th. Workshop Milestones: 26 May 2017, Call for Presentations posted and open for submissions 28 July 2017, Deadline for submission 11 August 2017, Draft Programme published 01 September 2017, Final Program published 15 September 2017, Final deadline for slideset submission Details for presentation submission will be published here: https://indico.dns-oarc.net/event/27/call-for-abstracts/ The workshop presentations will be organized by common themes, depending on the topics and the timing of each presentation. There are 30-minute and 15-minute slots, let us know your preference in your submission. To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> Ray Bellis, for the OARC Programme Committee OARC depends on sponorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- Mauricio Vergara Ereche Los Angeles, CA http://mave.cero32.cl

1 0

[dns-esp] Fwd: Call for Trusted Community Representatives
by Andres Pavez 19 May '17

19 May '17

Hola, Les reenvio informacion desde IANA/PTI por si estan interesados en aplicar para ser TCR y participar en las ceremonies de firma de la KSK. https://www.iana.org/help/tcr-application Saludos. -- Andrés Pavez On 5/18/17, 17:36, "root-dnssec-announce-bounces(a)icann.org on behalf of Kim Davies" <root-dnssec-announce-bounces(a)icann.org on behalf of kim.davies(a)iana.org> wrote: >We are seeking interested individuals who wish to act as Trusted >Community Representatives (TCRs). These individuals play an important >role in managing the Root Zone Key Signing Key (KSK), the trust anchor >for the global Domain Name System (DNS). By inviting recognized >members of the DNS technical community to be part of the Root Zone >KSK operations, the ICANN organization seeks to improve transparency >and confidence in the Domain Name System Security Extensions (DNSSEC) >security mechanism among the wider Internet community. > >About the TCR Role >------------------ > >TCRs serve as one of the multi-layered safeguards that protect the key >material used to secure the DNS Root Zone. > >There are two primary types of TCRs: cryptographic officers, who are >actively involved in Root Zone KSK ceremonies conducted throughout the >year; and recovery key share holders, who are involved in our disaster >recovery planning. The cryptographic officers make a commitment to >travel to a least one Root Zone KSK ceremony per year. > >All TCRs maintain custody of essential pieces required for the >successful operation of the Root Zone KSK. To guard against unauthorized >access, management of the KSK is spread across multiple individuals who >must come together to operate the key. > >TCRs are ambassadors on behalf of the broader technical and operational >communities. To support trust in the system, TCRs report back to the >community that the Root Zone KSK is being managed in an appropriate and >trustworthy way. > >All TCRs need to maintain a state of readiness should there be an >unforeseen need to hold a ceremony at short notice. > >Travel support is provided to TCRs who need to attend ceremonies. This >support includes arranging and paying for airfare and accommodation, and >providing a stipend for incidental costs. > >More Information >---------------- > >Those who are interested in applying to be a TCR are invited to review >detailed materials posted on the IANA website, which includes the >process to submit a statement of interest. Statements of interest will >be collected and assessed to fill current vacancies, and in the event of >new vacancies. > >Visit here: >https://urldefense.proofpoint.com/v2/url?u=https-3A__iana.org_tcr&d=DwICAg >&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=foU9Usw18Mt-lQEEtQUqT9Fet >K603awyEWUhExAm2uE&m=vIQa8DtxnkaI0dQwPNEb5MfqmcwMNSvM2IUhpfzmevw&s=R_fWWbc >ALHEl5jcSY2QBvOuMnbDEvwaMLhZYYFhUvrM&e= > > >Kim Davies >Director, Technical Services > >_______________________________________________ >root-dnssec-announce mailing list >root-dnssec-announce(a)icann.org >https://mm.icann.org/mailman/listinfo/root-dnssec-announce

1 0

[dns-esp] Monitorear cantidad de Query por dominio
by Carlos Tirado 05 May '17

05 May '17

Estimados. Existe forma de conocer (tener estadisticas) de la cantidad de querys que son recibidas en forma mensual en nuestros NS por cada dominio que esta siendo servidor desde nuestros BIND? Hago esta consulta por la simple razon que deseo evaluar migrar dominios hacia un proveedor de DNS Cloud que cobra por cantidad de querys mensuales Saludos! -- Carlos Tirado Elgueta Google Cloud Partner G Suite Specialist. http://www.chilemedios.cl

6 5

[dns-esp] LImitar la cantidad de registros A en la sección ANSWER
by Carlos M. Martinez 05 May '17

05 May '17

Hola a todos, Tengo la siguiente situación. Estamos realizando un experimento para el que hemos creado una zona DNS, “africa-connectivity.exp.dev.lacnic.net”, la cual tiene varios cientos de registros A, lo que resulta en una respuesta de casi 3700 bytes. Resolverlo desde un PC normal, funciona perfectamente. Sin embargo, algunos resolvers que están limitados a usar UDP, o están detrás de firewalls, tienen problemas. Me gustaría poder hacer que cuando se recibe una consulta por este nombre, mi servidor DNS devolviera solamente un subconjunto de los registros A de la zona. ¿Es eso posible con algún servidor de nombres de los conocidos? Estoy evitando tener que escribir algo de uso especial. ¡Gracias! -Carlos

5 8

[dns-esp] Proveedores redundantes de DNS, la experiencia de The Guardian
by Hugo Salgado-Hernández 28 Apr '17

28 Apr '17

Hola. Después del último ataque DoS a Dyn que dejó fuera varios dominios famosos, se puso de moda tener "proveedores redundantes" de DNS. O sea ya no basta lo bueno que sea cualquier proveedor, siempre puede quedar fuera con un DoS gigante. Así que la solución es tener al menos dos. El problema entonces es que cada uno tiene su propia tecnología o API, por lo que la complicación es automatizar las dos. Este es un muy buen artículo de los developers de The Guardian con su experiencia con Dyn y Route 53: <https://www.theguardian.com/info/developer-blog/2016/dec/23/multiple-dns-sy…> Por supuesto que nada de esto sería problema si se estandarizara la forma de alimentar los secundarios, que... sorpresa! Existe desde hace 20 años (AXFR/IXFR) ;) Saludos, Hugo

2 4

[dns-esp] Fwd: [DNSOP] b-root begins anycast in May
by Alejandro Acosta 20 Apr '17

20 Apr '17

Interesante. FYI -------- Mensaje reenviado -------- Asunto: [DNSOP] b-root begins anycast in May Fecha: Tue, 18 Apr 2017 21:23:10 -0700 De: John Heidemann <johnh(a)isi.edu> Para: dnsop <dnsop(a)ietf.org> [This topic is not directly relevant to dnsop working group events, but the WG overlaps with the right set of technical folks, so pardon the distraction.] To improve B-Root DNS service, B-Root will be activating anycast on 2017-05-01, providing service from a new site in Miami in addition to our current site in Los Angeles. We thank Florida International University (https://www.fiu.edu) and Ampath.net (https://ampath.net) for hosting our new hardware there, and USC (https://www.usc.edu) for hardware support for this second site. As part of this deployment, we will be renumbering B-Root's IPv6 address to 2001:500:200::b, effective on 2017-06-01 (pending final coordination with IANA). We also plan renumber our IPv4 address later in 2017; we will announce that date here. Renumbering will help support anycast with more resilient routing. (We will provide service on our old IPv6 and IPv4 addresses for at least one year after renumbering.) Please address any questions about B-Root operations to b-poc (at) isi.edu. _______________________________________________ DNSOP mailing list DNSOP(a)ietf.org https://www.ietf.org/mailman/listinfo/dnsop

4 4

[dns-esp] Transferencia de reversos inter-RIRs
by Hugo Salgado-Hernández 08 Apr '17

08 Apr '17

Hola. No se si supieron que hubo un problema hace unas semanas con los reversos de RIPE, que dejó fuera a varias organizaciones. Hoy publicaron un reporte: <https://labs.ripe.net/Members/anandb/reverse-dns-outage-for-out-of-region-a…> No tenía idea del mecanismo de "zonelets" para informarse de transferencias de bloques entre regiones. Es interesante problema! Se me ocurre que una solución podría ser usar DNAMEs delegando al nombre a una zona bajo control del RIR de destino. Siguiendo el ejemplo mencionado en el artículo, RIPE podría publicar algo como: 122.193.in-addr.arpa. IN DNAME 122.193.in-addr.arin.net. esto suponiendo que RIPE conoce de antemano que el recurso fue transferido a ARIN (que *espero* sea ese el caso :) ) Esto deja la responsabilidad de publicar los NS al que realmente corresponde, que es ARIN. DNAME tiene bastante despliegue, y además se puede sintetizar en tiempo real, para ser "retro-compatible". La gente de LACNIC, sabe si esta solución se está discutiendo como alternativa a los zonelets? Saludos, Hugo

5 6

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

DNS LACNOG