- Buscador - lactld.org

Reunión del 12 de octubre // October 12nd meeting
by Santiago Fernández Ruiz 08 Oct '21

08 Oct '21

(English below) Estimados, Les recordamos que el próximo *martes 12* tendremos nuestra reunión bisemanal a las *16 UTC*. En esta ocasión, tal como ha mencionado José, se discutirá principalmente la integración vía RDAP. Por ende, reiteramos la invitación al .BR, .CL, .CO (los ccTLD integrados vía RDAP) y .MX (quien tenía pensado integrarse de esta manera) a participar junto a quien consideren de ayuda dentro de sus equipos para poder abordar esta temática. ¡Los esperamos! Saludos -- Dear all, We remind you that next *Tuesday (October, 12nd)* we will have our biweekly meeting at* 16 UTC*. On this occasion, as José mentioned, we will mainly discuss the integration via RDAP. Therefore, we reiterate the invitation to .BR, .CL, .CO (the ccTLDs integrated via RDAP) and .MX (who had planned to integrate in this way) to participate together with whoever they consider helpful within their teams to address this issue. We look forward to seeing you! Best regards *Buscador Unificado de DominiosUnified Domain Search Engine* *Webinar* ------------------------------ *Reunión bisemanalBiweekly meeting* ------------------------------ Martes 12 de octubre / *Tuesday, October 12nd* 16.00 UTC ------------------------------ Unirse a la reunión / *Join meeting* Zoom ES / EN <https://us02web.zoom.us/webinar/register/WN_Hhk6jLYuQUu9maN77Z6YTQ> Clave / Password: LACTLD2020 [image: Facebook] <http://www.facebook.com/> [image: Twitter] <http://www.twitter.com/> [image: Website] <http://www.yourwebsite.com/> Copyright © 2020 LACTLD, All rights reserved. -- *Santiago Fernández Ruiz* Communications Officer *M:* santiago(a)staff.lactld.org *T:* +54 9 1130473172 *W:* www.lactld.org

1 0

Presentación próxima reunión
by José Urzúa 08 Oct '21

08 Oct '21

¡Buenas tardes! Les escribo porque dejé disponible en “el drive” del proyecto una presentación para la reunión del martes, en la cual revisaremos la integración entre el buscador y RDAP: https://docs.google.com/presentation/d/1WNOK4ii28e5I8AXqG-LrEP5zb2DfzuXt7gv… <https://docs.google.com/presentation/d/1WNOK4ii28e5I8AXqG-LrEP5zb2DfzuXt7gv…> Intenté resumir bien el problema y se agregan las propuestas sobre las cuales espero podamos discutir. Quedo atento por si olvidé algo o si hay cualquier sugerencia. ¡Saludos y buen fin de semana! -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile

1 0

Re: [BUD] Consulta RDAP - reddog
by José Urzúa 05 Oct '21

05 Oct '21

Estimado Alberto Muchas gracias por su detallada respuesta. Agrego mis comentarios entre líneas: > El 05-10-2021, a las 14:22, Alberto Leiva Popper <aleiva(a)nic.mx> escribió: > > Ok, estoy dispuesto a hacer modificaciones al proyecto si tienen una buena razón de ser, pero por lo que entiendo, pareces estar tratando de solucionar el problema en el lugar incorrecto. Esta es la idea de poder consultar con usted, saber su opinión y recomendación al respecto. > Si tienes un cliente que consulta muchos servidores estándares, y necesitas una funcionalidad que solamente le sirve a tu cliente... la solución no es hacer a los servidores no estándares; la solución es ponerle la funcionalidad al cliente. Estoy de acuerdo con lo que plantea en forma general. En este tema puntal de RDAP, nos encontramos con una respuesta “Not found” para una consulta de un nombre que *no* puede ser inscrito porque tiene caracteres no soportados en el ccTLD y nos gustaría saber si es posible con RDAP diferenciar ese caso. Esta misma consulta la envié a Francisco Arias de ICANN (también fue recomendación de José Ernesto Grimaldo), Francisco revisó el caso con Gustavo Lozano y Eduardo Alvarez, finalmente me comentaron estas tres alternativas para abordar el tema desde el lado de RDAP: ===== copy&paste===== 1. Crear una extensión de RDAP para este propósito. Por ejemplo, Gustavo sugería: registrableDomain/<domain> , 200 - si, 404 - no. Es probablemente la opción mas limpia, pero require algo de trabajo para documentarla y registrarla en IANA. Una propuesta más compleja, y ahora abandonada la puedes ver en https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-domain-avail… <https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-domain-avail…> 2. Eduardo sugiere usar el "Error response body" como se describe en sección del RFC 9083. No require estandarización, por tanto es relativamente fácil de implementar, basta con que los ccTLDs participantes se pongan de acuerdo en que poner en la respuesta para indicar si el dominio se puede registrar o no. Por no ser estandarizado, solo los participantes que sepan de ello lo entenderán. 3. Registrar un nueve código HTTP. No estoy seguro cuál es el proceso, el registro de los códigos en IANA https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml <https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml> dice que se require "IETF review", lo que suena complicado, sobre todo tomando en cuenta que probablemente habría que encontrar una propuesta de uso general. ===== copy&paste===== Creo que cada una requiere de un tiempo que no será menor y no creo que sea muy rápida la adopción. Me gustaría promover una extensión a RDAP para abordar este caso, pero eso sería un camino paralelo al desarrollo del proyecto del buscador de dominios de LACTLD, pues no podemos esperar a que se haga esa adopción para poder continuar con el desarrollo en nuestro grupo de trabajo. > ¿Qué te detiene a analizar la string antes de enviársela al servidor? Para el caso de labels latinoamericanas, me parece que no debería ser mucho problema validar los caracteres permitidos; no parecen ser muchos. Esta es otra alternativa que también estamos evaluando y probablemente sea la que adoptemos. Con el uso de IDN el conjunto de caracteres permitidos sí pueden ser muchos y distintos en cada ccTLD. Actualmente, la aplicación de LACTLD hace consultas para dominios .CO, .BR y .CL usando RDAP y en los tres el conjunto de caracteres permitidos es diferente. Personalmente creo que lo más probable es que terminemos desarrollando una nueva componente que tendrá la rutina de validación de sintaxis de nombre para cada ccTLD que se integra usando RDAP y en caso de ser válido el nombre, se envía la consulta por RDAP al ccTLD. Tendremos que asumir el costo de mantener actualizada esa componente en los casos que los ccTLD actualicen sus reglas (no es algo tan frecuente), pero pareciera ser mejor que esperar una estandarización de una nueva funcionalidad de RDAP. Agradezco de sobremanera su tiempo y respuesta a nuestra consulta, nos será de mucha utilidad para las decisiones que debemos tomar. Saludos, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile > > De: Alberto Leiva Popper <aleiva(a)nic.mx <mailto:aleiva@nic.mx>> > Enviado: martes, 5 de octubre de 2021 10:58 > Para: José Urzúa <jose(a)nic.cl> > Cc: buscador(a)lactld.org <buscador(a)lactld.org> > Asunto: RE: Consulta RDAP - reddog > > Hola > > Una disculpa; este correo me cayó a la carpeta de spam; acabo de encontrarlo. > > Ahora mismo voy a ponerme a investigar si es factible hacer esto. > > Alberto > De: José Urzúa <jose(a)nic.cl> > Enviado: martes, 14 de septiembre de 2021 17:01 > Para: Alberto Leiva Popper <aleiva(a)nic.mx> > Cc: buscador(a)lactld.org <buscador(a)lactld.org> > Asunto: Consulta RDAP - reddog > > Estimado Alberto > > Espero que se encuentre muy bien. Mi nombre es José Urzúa, trabajo para NIC Chile (.CL) y le escribo porque soy parte del grupo de trabajo de LACTLD que está desarrollando un buscador de dominios regional. En este grupo también participa José Ernesto Grimaldo y él nos comentó que podemos contactarlo por el tema que paso a explicar: > > De forma muy resumida, el buscador de dominios permite que un usuario pueda saber si un nombre está disponible para inscripción en la región, informando las distintas alternativas que existen en cada ccTLD participante. La aplicación “buscador”, obtiene esa información consultando a cada ccTLD y una forma de consultar es usando el servicio RDAP que algunos países tienen disponible. Por ejemplo, en el caso de .CL tenemos RDAP disponible por medio de reddog. Pero al realizar pruebas con nombres de dominio internacionalizados (IDN) nos encontramos con un caso que nos generó la duda: al consultar por un nombre de dominio que no está inscrito recibo una respuesta con código 404 "Not found”, lo que me parece bien y así podemos mostrar en el buscador que ese nombre está disponible. Pero si consulto por un dominio que “no se puede inscribir”, porque incluye caracteres no soportados por el ccTLD, también obtengo una respuesta con código 404, lo que erróneamente nos lleva a considerar que ese dominio sí está disponible para inscripción, cuando en realidad ese dominio no se podrá inscribir. Estuve mirando los RFC de RDAP y me parece que este comportamiento es acorde a lo que dice el RFC, pero no es acorde al uso que necesitamos en el buscador de dominios de LACTLD. > > ¿Usted sabe si hay forma de diferenciar estos casos en RDAP? > > Por ejemplo, para el caso de .CL, me gustaría poder diferenciar entre las respuestas por: > > 1- consulta por un dominio IDN disponible que se puede inscribir: diseño-qwerty.cl > 2- consulta por un dominio IDN que no se puede inscribir porque no hay soporte para estos caracteres en el ccTLD: diseño-例子.cl > > Para el segundo caso, sería ideal que RDAP me responda con un código 400 Bad request u otro que indique que ese nombre no es válido en el ccTLD. > > De antemano, agradezco su tiempo y espero se haya entendido la consulta que estamos abordando en el grupo de trabajo. > > Saludos cordiales, > -- > José Urzúa > Jefe Desarrollo de Sistemas > NIC Chile - Universidad de Chile > > Este mensaje contiene información confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sada 427 Piso 2 Local 1 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaciones y notificaciones; la transferencia y publicación en los casos aplicables; el cumplimiento de la relación existente; así como para la prevención o denuncia en la comisión de ilícitos. Si eres colaborador o candidato a colaborador de NIC México, tus datos serán utilizados para: la creación y administración de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administración de servicios de pago y/o nómina; así como para contacto y/o notificaciones. Si participas en promociones o en estudios podrás dejar de participar. Para mayor información revisa el Aviso de Privacidad (https://www.nicmexico.mx/es-nicmx-avisosdeprivacidad) > > This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center, S.A. de C.V., located on Av. Eugenio Garza Sada 427 Piso 2 Local 1, Col. Altavista, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note (https://www.nicmexico.mx/es-nicmx-avisosdeprivacidad/)

1 0

[RECORDATORIO / REMINDER] Reunión del 1 de octubre // October 1st meeting
by Santiago Fernández Ruiz 30 Sep '21

30 Sep '21

*Buscador Unificado de DominiosUnified Domain Search Engine* *Webinar* ------------------------------ *Reunión bisemanalBiweekly meeting* ------------------------------ Viernes 1 de octubre / *Friday, October 1st* 16.00 UTC ------------------------------ Unirse a la reunión / *Join meeting* Zoom ES / EN <https://us02web.zoom.us/webinar/register/WN_Hhk6jLYuQUu9maN77Z6YTQ> Clave / Password: LACTLD2020 [image: Facebook] <http://www.facebook.com/> [image: Twitter] <http://www.twitter.com/> [image: Website] <http://www.yourwebsite.com/> Copyright © 2020 LACTLD, All rights reserved. -- *Santiago Fernández Ruiz* Communications Officer *M:* santiago(a)staff.lactld.org *T:* +54 9 1130473172 *W:* www.lactld.org

1 0

Reunión del 1 de octubre // October 1st meeting
by Santiago Fernández Ruiz 27 Sep '21

27 Sep '21

*Buscador Unificado de DominiosUnified Domain Search Engine* *Webinar* ------------------------------ *Reunión bisemanalBiweekly meeting* ------------------------------ Viernes 1 de octubre / *Friday, October 1st* 16.00 UTC ------------------------------ Unirse a la reunión / *Join meeting* Zoom ES / EN <https://us02web.zoom.us/webinar/register/WN_Hhk6jLYuQUu9maN77Z6YTQ> Clave / Password: LACTLD2020 [image: Facebook] <http://www.facebook.com/> [image: Twitter] <http://www.twitter.com/> [image: Website] <http://www.yourwebsite.com/> Copyright © 2020 LACTLD, All rights reserved. -- *Santiago Fernández Ruiz* Communications Officer *M:* santiago(a)staff.lactld.org *T:* +54 9 1130473172 *W:* www.lactld.org

1 0

Re: [BUD] [Ext] Consulta RDAP y dominio disponible
by José Urzúa 20 Sep '21

20 Sep '21

Estimado Francisco, Muchas gracias por su respuesta. Con el grupo de trabajo revisaremos en detalle las alternativas planteadas. Personalmente, me gusta bastante la alternativa 1 y agradezco la referencia la propuesta abandonada. Saludos cordiales, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile > El 17-09-2021, a las 21:17, Francisco Arias Correa <francisco.arias(a)icann.org> escribió: > > Que tal José: > > Con gusto trataremos de ayudar. Estoy incluyendo en este mensaje a Gustavo y Eduardo que en mi equipo aquí en ICANN trabajan en RDAP. > > De entrada, el RFC 7480 menciona que en RDAP se puede usar cualquier código HTTP. Sin embargo, no encuentro ninguno que me haga sentido para el caso de uso que mencionas. Después de platicar el tema con Gustavo y Eduardo llegamos a tres alternativas que listo a continaución: > > 1. Crear una extensión de RDAP para este propósito. Por ejemplo, Gustavo sugería: registrableDomain/<domain> , 200 - si, 404 - no. Es probablemente la opción mas limpia, pero require algo de trabajo para documentarla y registrarla en IANA. Una propuesta más compleja, y ahora abandonada la puedes ver en https://datatracker.ietf.org/doc/html/draft-newton-regext-rdap-domain-avail… > > 2. Eduardo sugiere usar el "Error response body" como se describe en sección del RFC 9083. No require estandarización, por tanto es relativamente fácil de implementar, basta con que los ccTLDs participantes se pongan de acuerdo en que poner en la respuesta para indicar si el dominio se puede registrar o no. Por no ser estandarizado, solo los participantes que sepan de ello lo entenderán. > > 3. Registrar un nueve código HTTP. No estoy seguro cuál es el proceso, el registro de los códigos en IANA https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml dice que se require "IETF review", lo que suena complicado, sobre todo tomando en cuenta que probablemente habría que encontrar una propuesta de uso general. > > Saludos, > > -- > Francisco. > > > > On 9/16/21, 10:26, "José Urzúa" <jose(a)nic.cl> wrote: > > Estimado Francisco > > Espero que se encuentre muy bien. Mi nombre es José Urzúa, trabajo para NIC Chile (.CL) y le escribo porque soy parte del grupo de trabajo de LACTLD que está desarrollando un buscador de dominios regional (en copia de este correo). En este grupo también participa José Ernesto Grimaldo y él nos comentó que podemos contactarlo por el tema que paso a explicar: > > De forma muy resumida, el buscador de dominios permite que un usuario pueda saber si un nombre está disponible para inscripción en la región, informando las distintas alternativas que existen en cada ccTLD participante. La aplicación “buscador”, obtiene esa información consultando a cada ccTLD y una forma de consultar es usando el servicio RDAP que algunos países tienen disponible. Por ejemplo, en el caso de .CL tenemos RDAP disponible por medio de reddog. Pero al realizar pruebas con nombres de dominio internacionalizados (IDN) nos encontramos con un caso que nos generó la duda: al consultar por un nombre de dominio que no está inscrito recibo una respuesta con código 404 "Not found”, lo que me parece bien y así podemos mostrar en el buscador que ese nombre está disponible. Pero si consulto por un dominio que “no se puede inscribir”, porque incluye caracteres no soportados por el ccTLD, también obtengo una respuesta con código 404, lo que erróneamente nos lleva a considerar que ese dominio sí está disponible para inscripción, cuando en realidad ese dominio no se podrá inscribir. Estuve mirando los RFC de RDAP y me parece que este comportamiento es acorde a lo que dice el RFC. > > ¿Usted sabe si hay forma de diferenciar estos casos en RDAP? > > Por ejemplo, para el caso de .CL, me gustaría poder diferenciar entre las respuestas por: > > 1- consulta por un dominio IDN disponible que se puede inscribir: diseño-qwerty.cl > 2- consulta por un dominio IDN que no se puede inscribir porque no hay soporte para estos caracteres en el ccTLD: diseño-例子.cl > > En mi opinión, para el segundo caso sería ideal que RDAP me responda con un código 400 Bad request u otro que indique que ese nombre no es válido en el ccTLD. > > De antemano, agradezco su tiempo y espero se haya entendido la consulta que estamos abordando en el grupo de trabajo. > > Saludos cordiales, > -- > José Urzúa > Jefe Desarrollo de Sistemas > NIC Chile - Universidad de Chile >

1 0

Reunión del 28 de septiembre // September 28th meeting
by Santiago Fernández Ruiz 17 Sep '21

17 Sep '21

(English below) Estimados, Espero estén muy bien. Ayer olvidé mencionar que nuestra próxima reunión (28 de septiembre) coincide con uno de los días del Taller de Políticas y Legal. Por lo tanto, quería presentarles 4 planes alternativos: - Atrasar la reunión ese mismo 28/9 a las 18:30 / 19 UTC - Adelantar la reunión al martes que viene (21 de septiembre, 16 UTC) - Mover la reunión al viernes 1 de octubre (16 UTC) - Cancelar la reunión y esperar directamente al 12 de octubre Quedo atento a sus indicaciones, Saludos! ----- Dear all, I hope you are doing well. Yesterday I forgot to mention that our next meeting (September 28) overlaps with one of the days of the Policy and Legal Workshop. Therefore, I wanted to present you with 4 alternative plans: - Delay the meeting that same September 28th at 18:30 / 19 UTC. - Move the meeting to next Tuesday (September 21, 16 UTC) - Move the meeting to Friday October 1st (16 UTC) - Cancel the meeting and wait directly for October 12. I look forward to hearing from you, Best regards! -- *Santiago Fernández Ruiz* Communications Officer *M:* santiago(a)staff.lactld.org *T:* +54 9 1130473172 *W:* www.lactld.org

7 7

Consulta RDAP y dominio disponible
by José Urzúa 16 Sep '21

16 Sep '21

Estimado Francisco Espero que se encuentre muy bien. Mi nombre es José Urzúa, trabajo para NIC Chile (.CL) y le escribo porque soy parte del grupo de trabajo de LACTLD que está desarrollando un buscador de dominios regional (en copia de este correo). En este grupo también participa José Ernesto Grimaldo y él nos comentó que podemos contactarlo por el tema que paso a explicar: De forma muy resumida, el buscador de dominios permite que un usuario pueda saber si un nombre está disponible para inscripción en la región, informando las distintas alternativas que existen en cada ccTLD participante. La aplicación “buscador”, obtiene esa información consultando a cada ccTLD y una forma de consultar es usando el servicio RDAP que algunos países tienen disponible. Por ejemplo, en el caso de .CL tenemos RDAP disponible por medio de reddog. Pero al realizar pruebas con nombres de dominio internacionalizados (IDN) nos encontramos con un caso que nos generó la duda: al consultar por un nombre de dominio que no está inscrito recibo una respuesta con código 404 "Not found”, lo que me parece bien y así podemos mostrar en el buscador que ese nombre está disponible. Pero si consulto por un dominio que “no se puede inscribir”, porque incluye caracteres no soportados por el ccTLD, también obtengo una respuesta con código 404, lo que erróneamente nos lleva a considerar que ese dominio sí está disponible para inscripción, cuando en realidad ese dominio no se podrá inscribir. Estuve mirando los RFC de RDAP y me parece que este comportamiento es acorde a lo que dice el RFC. ¿Usted sabe si hay forma de diferenciar estos casos en RDAP? Por ejemplo, para el caso de .CL, me gustaría poder diferenciar entre las respuestas por: 1- consulta por un dominio IDN disponible que se puede inscribir: diseño-qwerty.cl 2- consulta por un dominio IDN que no se puede inscribir porque no hay soporte para estos caracteres en el ccTLD: diseño-例子.cl En mi opinión, para el segundo caso sería ideal que RDAP me responda con un código 400 Bad request u otro que indique que ese nombre no es válido en el ccTLD. De antemano, agradezco su tiempo y espero se haya entendido la consulta que estamos abordando en el grupo de trabajo. Saludos cordiales, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile

1 0

FW: Contacto para dudas de RDAP
by Jose Ernesto Grimaldo Tijerina 15 Sep '21

15 Sep '21

Hola a Todos. Adicionalmente les comparto el contacto en ICANN para dudas más específicas sobre RDAP. Francisco Arias francisco.arias(a)icann.org<mailto:francisco.arias@icann.org> Las consultas pueden ir en español sin problema. Saludos! José Ernesto Grimaldo | NIC México Este mensaje contiene información confidencial y se entiende dirigido y para uso exclusivo del destinatario. Si recibes este mensaje y no eres el destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar cualquier acción basada en el contenido está estrictamente prohibido. Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza Sada 427 Piso 2 Local 1 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus datos personales necesarios para: la prestación, estudio, análisis y mejora del servicio, la realización de comunicaciones y notificaciones; la transferencia y publicación en los casos aplicables; el cumplimiento de la relación existente; así como para la prevención o denuncia en la comisión de ilícitos. Si eres colaborador o candidato a colaborador de NIC México, tus datos serán utilizados para: la creación y administración de tu perfil como profesionista; el otorgamiento de herramientas de trabajo; la realización de estudios; el otorgamiento de programas y beneficios para mejorar tu desarrollo profesional; la gestión y administración de servicios de pago y/o nómina; así como para contacto y/o notificaciones. Si participas en promociones o en estudios podrás dejar de participar. Para mayor información revisa el Aviso de Privacidad (https://www.nicmexico.mx/es-nicmx-avisosdeprivacidad) This message contains confidential information and is intended only for the individual named. If you are not the named addressee please delete it, since the dissemination, distribuition, copy or taking any action in reliance on the contents is strictly prohibited. Network Information Center, S.A. de C.V., located on Av. Eugenio Garza Sada 427 Piso 2 Local 1, Col. Altavista, Monterrey, Mexico, CP 64840 collects your personal data which is necessary to: provide, research, analyze and improve the service; send communications and notices; transfer and publish your personal data when applicable; fulfill the existing relationship; prevent or inform in the commission of unlawful acts or events. If the data is processed in your quality of candidate or collaborator of NIC Mexico, the purpose of treatment is to: create and manage your profile as a professional; provide you with working tools; conduct studies; grant benefits and programs to enhance your professional development; manage and administrate payment services and/or payroll; as well as to contact you. If you participate in promotions or surveys you may stop or quit your participation at any time. For more information read the Privacy Note (https://www.nicmexico.mx/es-nicmx-avisosdeprivacidad/)

1 0

Consulta RDAP - reddog
by José Urzúa 14 Sep '21

14 Sep '21

Estimado Alberto Espero que se encuentre muy bien. Mi nombre es José Urzúa, trabajo para NIC Chile (.CL) y le escribo porque soy parte del grupo de trabajo de LACTLD que está desarrollando un buscador de dominios regional. En este grupo también participa José Ernesto Grimaldo y él nos comentó que podemos contactarlo por el tema que paso a explicar: De forma muy resumida, el buscador de dominios permite que un usuario pueda saber si un nombre está disponible para inscripción en la región, informando las distintas alternativas que existen en cada ccTLD participante. La aplicación “buscador”, obtiene esa información consultando a cada ccTLD y una forma de consultar es usando el servicio RDAP que algunos países tienen disponible. Por ejemplo, en el caso de .CL tenemos RDAP disponible por medio de reddog. Pero al realizar pruebas con nombres de dominio internacionalizados (IDN) nos encontramos con un caso que nos generó la duda: al consultar por un nombre de dominio que no está inscrito recibo una respuesta con código 404 "Not found”, lo que me parece bien y así podemos mostrar en el buscador que ese nombre está disponible. Pero si consulto por un dominio que “no se puede inscribir”, porque incluye caracteres no soportados por el ccTLD, también obtengo una respuesta con código 404, lo que erróneamente nos lleva a considerar que ese dominio sí está disponible para inscripción, cuando en realidad ese dominio no se podrá inscribir. Estuve mirando los RFC de RDAP y me parece que este comportamiento es acorde a lo que dice el RFC, pero no es acorde al uso que necesitamos en el buscador de dominios de LACTLD. ¿Usted sabe si hay forma de diferenciar estos casos en RDAP? Por ejemplo, para el caso de .CL, me gustaría poder diferenciar entre las respuestas por: 1- consulta por un dominio IDN disponible que se puede inscribir: diseño-qwerty.cl 2- consulta por un dominio IDN que no se puede inscribir porque no hay soporte para estos caracteres en el ccTLD: diseño-例子.cl Para el segundo caso, sería ideal que RDAP me responda con un código 400 Bad request u otro que indique que ese nombre no es válido en el ccTLD. De antemano, agradezco su tiempo y espero se haya entendido la consulta que estamos abordando en el grupo de trabajo. Saludos cordiales, -- José Urzúa Jefe Desarrollo de Sistemas NIC Chile - Universidad de Chile

1 0