Continuando con la aventura de mi anterior post las guerras de conexión a la VPN https://social.morettigiuseppe.com/o/a37ae557ee4c4938a40555737bd5ae96, tuve otra desconexión. Mi re-resolver funcionaba, ejecutaba correctamente, pero el server remoto era incapaz de resolver la dirección de mi server local (Wireguard server). La dirección en cuestion es un subdominio de duckdns. Probé con otros y al parecer no resolvía ninguno de los subdominios, pero si cualquier otro dominio. Extraño. En una situación normal de problemas de DNS, cambiaría a los DNS de Google o Cloudflare directamente. Cosa que hice. Pero al cambiar se perdía la conexión. En algún foro leí que algunos ISP pueden restringir cualquier petición al puerto 53 (puerto de peticiones DNS) que no sea la de su propio servidor DNS, precisamente para poder controlar el trafico. Me servío en ese momento como explicación. Es posible que al estar usando los servidores DNS del ISP me estuvieran bloqueando el acceso a mi subdominio por detectar un alto trafico hacia esa dirección? No tengo pruebas, pero tampoco dudas.

Al investigar por soluciones, muchos apuntaban a DoH (DNS over HTTPS), basicamente pedir resoluciónes de DNS por un canal cifrado HTTPS de tal manera que sea indistinguible del tráfico normal de Internet. Leyendo mas, encontré una imagen de docker que viene con una instalación de PiHole (que por cierto recomiendo muchisimo. Basicamente es tu servidor DNS local que bloquea todo tipo de anuncios y tracking a nivel de red :chefkiss:) y ademas trae DoH por Cloudflare, todo preconfigurado. https://github.com/aazam476/pihole-doh

Como solo resolvería las peticiones del mismo servidor donde esta instalado, una pequeña prueba. host elsubdominioencuestion.duckdns.org 127.0.0.1

voila! Lo que antes era incapaz de resolver ahora me devuelve la IP correcta. Remplazar el server DNS preconfigurado por localhost y servir!

Veremos cuanto dura, pero de momento este asalto contra el ISP, lo ganamos nosotros.