Mejoramos el DNS autoritativo con el lanzamiento oficial de Foundation DNS

Nos complace anunciar el lanzamiento oficial de Foundation DNS, con nuevos servidores de nombres avanzados, aún más resiliencia, y análisis avanzados para satisfacer los complejos requisitos de nuestros clientes del plan Enterprise. Foundation DNS es uno de los mayores avances de Cloudflare en nuestra solución de DNS autoritativo desde su lanzamiento en 2010, y sabemos que nuestros clientes están interesados en un servicio de DNS autoritativo preparado para empresas con el máximo nivel de rendimiento, fiabilidad, seguridad, flexibilidad y análisis avanzados.

A partir de hoy, cada nuevo contrato Enterprise que incluya DNS autoritativo tendrá acceso al conjunto de funciones de Foundation DNS. Los clientes ya existentes del plan Enterprise tendrán a su disposición las funciones de Foundation DNS a lo largo de este año. Si eres un cliente Enterprise que ya utiliza nuestros servicios de DNS autoritativo, y te interesa conseguir Foundation DNS antes, ponte en contacto con tu equipo de cuenta y ellos podrán activarlo. Empecemos...

¿Por qué el DNS es tan importante?

Desde la perspectiva del usuario final, el DNS hace que Internet sea utilizable. El DNS es la guía telefónica de Internet que traduce nombres de host como www.cloudflare.com en las direcciones IP que nuestros navegadores, nuestras aplicaciones y nuestros dispositivos utilizan para conectarse a los servicios. Sin DNS, los usuarios tendrían que recordar direcciones IP como 108.162.193.147 o 2606:4700:58::adf5:3b93 cada vez que quisieran visitar un sitio web en su dispositivo móvil o de escritorio. Imagina tener que recordar un nombre tan complejo en lugar de simplemente www.cloudflare.com. El DNS se utiliza en todas las aplicaciones de los usuarios finales en Internet, desde las redes sociales hasta los portales bancarios y de la atención sanitaria. El uso de Internet por parte de cualquier persona depende totalmente del DNS.

Desde una perspectiva empresarial, el DNS es el primer paso para acceder a los sitios web y conectarse a las aplicaciones. Los dispositivos necesitan saber dónde conectarse para acceder a los servicios, autenticar a los usuarios y proporcionar la información solicitada. Una resolución rápida de las consultas de DNS puede marcar la diferencia entre que un sitio web o una aplicación se perciba como reactivo o no, y puede tener un impacto real en la experiencia del usuario.

Cuando se producen interrupciones del DNS, las repercusiones son evidentes. Imagina que tu sitio de comercio electrónico preferido no se carga, como sucedió con la interrupción que experimentó Dyn en 2016, que provocó la caída de varios sitios de comercio electrónico populares. O bien, si formas parte de una empresa y los clientes no pueden acceder a tu sitio web para comprar los productos o servicios que vendes, una interrupción del DNS literalmente te hará perder dinero. El DNS a menudo se da por sentado, pero no te equivoques: cuando no funcione correctamente, lo notarás. Afortunadamente, si utilizas el DNS autoritativo de Cloudflare, realmente no debes preocuparte por estos problemas.

Siempre es posible la mejora

Cloudflare lleva más de una década proporcionando servicios de DNS autoritativo. Nuestro servicio de DNS autoritativo aloja millones de dominios en muchos dominios de primer nivel (TLD) distintos. Tenemos clientes de todos los tamaños, desde dominios individuales con apenas unos pocos registros hasta clientes con decenas de millones de registros distribuidos en varios dominios. Nuestros clientes del plan Enterprise exigen legítimamente a nuestro servicio de DNS el máximo nivel de rendimiento, fiabilidad, seguridad y flexibilidad, así como análisis detallados. A nuestros clientes les encanta nuestro DNS autoritativo. Sin embargo, reconocemos que siempre es posible la mejora en algunas de esas categorías. Con ese objetivo, nos propusimos realizar algunas mejoras importantes en nuestra arquitectura de DNS, con nuevas funciones y cambios estructurales. Estamos orgullosos de llamar a esta solución mejorada Foundation DNS.

Te presentamos Foundation DNS

Como nuestra nueva solución de DNS autoritativo para empresas, Foundation DNS se ha diseñado para mejorar la fiabilidad, la seguridad, la flexibilidad y los análisis de nuestro servicio de DNS autoritativo existente. Antes de analizar más detalladamente Foundation DNS, aquí tienes un breve resumen de lo que Foundation DNS aporta a nuestra solución de DNS autoritativo:

• Los servidores de nombres avanzados ofrecen una fiabilidad del DNS aún mayor.
• Los nuevos ajustes de DNS definidos a nivel de zona proporcionan una configuración más flexible de los ajustes específicos de DNS.
• Las claves DNSSEC únicas por cuenta y zona proporcionan seguridad y flexibilidad adicionales para DNSSEC.
• Los análisis de DNS basados en GraphQL proporcionan aún más información sobre tus consultas de DNS.
• Un nuevo proceso de lanzamiento garantiza a los clientes del plan Enterprise la máxima estabilidad y fiabilidad.
• Precios de DNS más sencillos con cuotas más generosas para zonas DNS exclusivas y registros DNS.

Ahora, analicemos más detalladamente cada una de estas nuevas funciones de Foundation DNS:

Servidores de nombres avanzados

Con Foundation DNS, presentamos servidores de nombres avanzados centrados específicamente en mejorar la fiabilidad de tu empresa. Quizás estás familiarizado con nuestros servidores de nombres autoritativos estándar, que se presentan en pares por zona y utilizan nombres dentro del dominio .com de Cloudflare. Este es un ejemplo:

$ dig mycoolwebpage.xyz ns +noall +answer 
mycoolwebpage.xyz.	86400	IN	NS	kelly.ns.cloudflare.com.
mycoolwebpage.xyz.	86400	IN	NS	christian.ns.cloudflare.com.

Ahora, veamos la misma zona utilizando los servidores de nombres avanzados de Foundation DNS:

$ dig mycoolwebpage.xyz ns +noall +answer 
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.com.
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.net.
mycoolwebpage.xyz.	86400	IN	NS	blue.foundationdns.org.

Los servidores de nombres avanzados mejoran la fiabilidad de distintas formas. La primera mejora proviene del hecho que los servidores autoritativos de Foundation DNS se distribuyen en varios dominios de primer nivel (TLD). Esta estrategia ofrece protección contra las interrupciones de DNS y los ataques DDoS a gran escala, que podrían afectar a la infraestructura DNS de nivel superior, incluidos los servidores de nombres de primer nivel. Los servidores de nombres autoritativos de Foundation DNS ahora están ubicados en varias ramas de la estructura de árbol DNS global, lo que permite aislar aún más a nuestros clientes de estos posibles ataques e interrupciones.

Puede que también te hayas dado cuenta de que con Foundation DNS hay un servidor de nombres adicional en la lista. Sin duda es una mejora. Sin embargo, no es por la razón que podrías pensar. Si resolvemos cada uno de estos servidores de nombres en sus respectivas direcciones IP, podemos hacer que el proceso sea un poco más fácil de entender. Es lo que haremos aquí, empezando por nuestros servidores de nombres estándar:

$ dig kelly.ns.cloudflare.com. +noall +answer
kelly.ns.cloudflare.com. 86353  IN      A       108.162.194.91
kelly.ns.cloudflare.com. 86353  IN      A       162.159.38.91
kelly.ns.cloudflare.com. 86353  IN      A       172.64.34.91

$ dig christian.ns.cloudflare.com. +noall +answer
christian.ns.cloudflare.com. 86353 IN   A       108.162.195.247
christian.ns.cloudflare.com. 86353 IN   A       162.159.44.247
christian.ns.cloudflare.com. 86353 IN   A       172.64.35.247

Hay seis direcciones IP en total para los dos servidores de nombres. Resulta que se trata del único aspecto que realmente les preocupa a los solucionadores DNS cuando consultan servidores de nombres autoritativos. Los solucionadores DNS no suelen realizar un seguimiento de los nombres de dominio reales de los servidores autoritativos; simplemente mantienen una lista desordenada de las direcciones IP que pueden utilizar para resolver las consultas correspondientes a un dominio determinado. De esta forma, con nuestros servidores de nombres autoritativos estándar, proporcionamos a los solucionadores seis direcciones IP para que las utilicen para resolver las consultas de DNS. Ahora veamos las direcciones IP de nuestros servidores de nombres avanzados de Foundation DNS:

$ dig blue.foundationdns.com. +noall +answer
blue.foundationdns.com. 300     IN      A       108.162.198.1
blue.foundationdns.com. 300     IN      A       162.159.60.1
blue.foundationdns.com. 300     IN      A       172.64.40.1

$ dig blue.foundationdns.net. +noall +answer
blue.foundationdns.net. 300     IN      A       108.162.198.1
blue.foundationdns.net. 300     IN      A       162.159.60.1
blue.foundationdns.net. 300     IN      A       172.64.40.1

$ dig blue.foundationdns.org. +noall +answer
blue.foundationdns.org. 300     IN      A       108.162.198.1
blue.foundationdns.org. 300     IN      A       162.159.60.1
blue.foundationdns.org. 300     IN      A       172.64.40.1

¡Mira eso! Foundation DNS proporciona la misma dirección IP para cada uno de los servidores de nombres autoritativos que proporcionamos a una zona. Así que, en este caso, solo hemos proporcionado tres direcciones IP para que los solucionadores las utilicen para resolver las consultas de DNS. Puede que te preguntes: "¿No es mejor seis que tres? ¿No es esto peor?" Resulta que más no siempre es mejor. Analicemos por qué.

Probablemente ya sabes que Cloudflare utiliza Anycast y, como puedes suponer, nuestros servicios de DNS utilizan Anycast para garantizar que nuestros servidores de DNS autoritativo están disponibles en todo el mundo y lo más cerca posible de los usuarios y los solucionadores de Internet. Todos nuestros servidores de nombres estándar se anuncian desde cada uno de los centros de datos de Cloudflare por un único grupo Anycast. Si realizamos un zoom sobre Europa, puedes ver que en una implementación de servidor de nombres estándar ambos servidores de nombres se anuncian desde cada centro de datos.

Podemos tomar esas seis direcciones IP de nuestros servidores de nombres estándar anteriores y realizar una búsqueda de su "hostname.bind". El registro TXT nos mostrará el código de aeropuerto o la ubicación física del centro de datos más cercano desde donde se resuelven nuestras consultas de DNS. Este resultado ayuda a explicar por qué más no siempre es mejor.

$ dig @108.162.194.91 ch txt hostname.bind +short
"LHR"

$ dig @162.159.38.91 ch txt hostname.bind +short
"LHR"

$ dig @172.64.34.91 ch txt hostname.bind +short
"LHR"

$ dig @108.162.195.247 ch txt hostname.bind +short
"LHR"

$ dig @162.159.44.247 ch txt hostname.bind +short
"LHR"

$ dig @172.64.35.247 ch txt hostname.bind +short
"LHR"

Como puedes ver, cuando se envía una consulta desde una ubicación cercana a Londres, las seis direcciones IP se enrutan al mismo centro de datos de Londres (LHR). Esto significa que, cuando un solucionador en Londres resuelve las consultas de DNS para un dominio utilizando el DNS autoritativo estándar de Cloudflare, independientemente de la dirección IP de servidor de nombres que se consulte, siempre se conecta a la misma ubicación física.

Quizás te estés preguntando: "¿Y qué? ¿Qué significa eso para mí?" Veamos un ejemplo. Si quisieras resolver un dominio utilizando los servidores de nombres estándar de Cloudflare de Londres, y estoy utilizando un solucionador público que también se encuentra en Londres, el solucionador siempre se conectará al centro de datos de Cloudflare LHR, independientemente del servidor de nombres al que intente acceder. No tiene ninguna otra opción, debido a Anycast.

Gracias a Anycast, si el centro de datos de LHR se desconectara por completo, todo el tráfico destinado a LHR se enrutaría a otros centros de datos cercanos y los solucionadores seguirían funcionando con normalidad. No obstante, en el caso improbable de que el centro de datos de LHR estuviera en línea pero nuestros servicios de DNS no pudieran responder a las consultas de DNS, el solucionador no tendría forma de resolver estas consultas de DNS, ya que no pueden acceder a ningún otro centro de datos. Podríamos tener 100 direcciones IP, y no nos ayudaría en esta situación. Con el tiempo, las respuestas almacenadas en la caché caducarán y el dominio dejará de resolverse.

Los servidores de nombres avanzados de Foundation DNS están cambiando la forma en que usamos Anycast, ya que utilizan dos grupos Anycast. Esto rompe el paradigma anterior de que cada dirección IP de servidor de nombres autoritativos se anuncia desde cada uno de los centros de datos. El uso de dos grupos Anycast significa que los servidores de nombres autoritativos de Foundation DNS en realidad tienen ubicaciones físicas distintas, en lugar de que todos se anuncien desde cada centro de datos. Este sería el aspecto de esa misma región utilizando dos grupos Anycast:

Retrocedamos y terminemos nuestra comparación de las seis direcciones IP autoritativas para DNS autoritativo estándar frente a las tres direcciones IP para Foundation DNS ahora que se entiende que Foundation DNS utiliza dos grupos Anycast para anunciar los servidores de nombres. Veamos desde dónde se anuncian los servidores de Foundation DNS en nuestro ejemplo:

$ dig @108.162.198.1 ch txt hostname.bind +short
"LHR"

$ dig @162.159.60.1 ch txt hostname.bind +short
"LHR"

$ dig @172.64.40.1 ch txt hostname.bind +short
"MAN"

¡Mira eso! Una de nuestras tres direcciones IP de servidor de nombres se anuncia desde un centro de datos distinto, Manchester (MAN), lo que hace que Foundation DNS sea más fiable y resiliente en la situación de interrupción mencionada anteriormente. Cabe mencionar que, en algunas ciudades, Cloudflare opera desde varios centros de datos, por lo que en este caso las tres consultas devolverían el mismo código de aeropuerto. Garantizamos que al menos una de esas direcciones IP se anuncia desde un centro de datos distinto, pero entendemos que algunos clientes pueden querer probarlo por sí mismos. En esos casos, una consulta adicional puede mostrar que las direcciones IP se anuncian desde distintos centros de datos.

$ dig @108.162.198.1 +nsid | grep NSID:
; NSID: 39 34 6d 33 39 ("94m39")

En el texto en negrita, el número que precede a la "m" representa el centro de datos que ha respondido a la consulta. Siempre que ese número sea distinto en una de las tres respuestas, sabrás que uno de tus servidores de nombres autoritativos de Foundation DNS se anuncia desde una ubicación física distinta.

Puesto que Foundation DNS utiliza dos grupos Anycast, la situación de interrupción anterior se gestiona sin problemas. Los solucionadores DNS supervisan las solicitudes a todos los servidores de nombres autoritativos devueltos para un dominio determinado, pero utilizan principalmente el servidor de nombres que proporciona las respuestas más rápidas.

Con esta configuración, los solucionadores DNS pueden enviar solicitudes a dos centros de datos de Cloudflare distintos. Por lo tanto, si se produce un fallo en una ubicación física, las consultas se envían automáticamente al segundo centro de datos, donde se pueden resolver adecuadamente.

Los servidores de nombres avanzados de Foundation DNS suponen un gran avance en materia de fiabilidad para nuestros clientes del plan Enterprise. Invitamos a nuestros clientes del plan Enterprise a activar hoy mismo los servidores de nombres avanzados para las zonas existentes. La migración a Foundation DNS tampoco implicará ningún tiempo de inactividad, porque incluso una vez que los servidores de nombres avanzados de Foundation DNS se hayan activado para una zona, los servidores de nombres DNS autoritativos estándar anteriores seguirán funcionando y respondiendo a las consultas de la zona. Para migrar a los servidores de nombres avanzados de Foundation DNS, los clientes no necesitan planificar una transición ni ningún otro evento que pudiera afectar al servicio.

Nueva configuración de DNS a nivel de zona

Históricamente, nuestros clientes del plan Enterprise nos han solicitado periódicamente ajustar configuraciones específicas de DNS que no estaban expuestas a través de nuestra API o nuestro panel de control, como activar anulaciones de DNS secundario. Cuando los clientes querían ajustar estas configuraciones, tenían que ponerse en contacto con sus equipos de cuenta, quienes se encargaban de realizar los cambios correspondientes. Con Foundation DNS, exponemos las configuraciones más solicitadas a través de la API y el panel de control para ofrecer a nuestros clientes una mayor flexibilidad con su solución de DNS autoritativo de Cloudflare.

Los clientes del plan Enterprise ahora pueden configurar los siguientes ajustes de DNS en sus zonas:

Claves DNSSEC únicas por cuenta y zona

DNSSEC (del inglés "Domain Name System Security Extensions") añade seguridad a un dominio o una zona proporcionando una forma de comprobar que la respuesta que recibes para una consulta de DNS es auténtica y no se ha modificado. DNSSEC previene el envenenamiento de caché DNS (suplantación de DNS), lo que ayuda a garantizar que los solucionadores DNS responden a las consultas de DNS con las direcciones IP correctas.

Desde que lanzamos Universal DNSSEC en 2015, hemos realizado un número considerable de mejoras, como añadir compatibilidad con DNSSEC prefirmado para zonas secundarias y DNSSEC multifirmante. Por defecto, Cloudflare firma los registros DNS sobre la marcha (firma en directo) cuando respondemos a las consultas de DNS. Esto permite a Cloudflare alojar un dominio protegido por DNSSEC, al mismo tiempo que asigna dinámicamente direcciones IP para los orígenes redireccionados mediante proxy. También admite determinados casos de uso de equilibrio de carga, ya que las direcciones IP que se proporcionan en la respuesta DNS en estos casos cambian en función del enrutamiento.

Cloudflare utiliza el algoritmo de curva elíptica ECDSA P-256, que es más seguro que la mayoría de las claves RSA que se utilizan hoy en día. Utiliza menos CPU para generar las firmas, lo que mejora la eficacia de su generación sobre la marcha. Se suelen utilizar dos claves como parte de DNSSEC: la clave de firma de zona (ZSK) y la clave de firma de clave (KSK). Explicado de la forma más sencilla, la ZSK se utiliza para firmar los registros DNS que se proporcionan en respuesta a las consultas y la KSK se utiliza para firmar las DNSKEY, incluida la ZSK para garantizar su autenticidad.

Hoy en día, Cloudflare utiliza una ZSK y una KSK compartidas a nivel mundial para todas las firmas de DNSSEC. Puesto que utilizamos un algoritmo criptográfico muy seguro, sabemos que este conjunto de claves está eficazmente protegido y, por lo tanto, no consideramos que sea necesario rotar periódicamente la ZSK o la KSK, al menos por razones de seguridad. Sin embargo, hay clientes que tienen políticas que requieren la rotación de estas claves cada cierto tiempo. Por ello, hemos añadido la posibilidad de que nuestros nuevos servidores de nombres avanzados de Foundation DNS roten tanto su ZSK como su KSK según sea necesario por cuenta o por zona. Estará función estará disponible primero mediante la API y posteriormente mediante el panel de control de Cloudflare. Por lo tanto, ahora los clientes sujetos a requisitos de políticas estrictas en relación con la rotación de sus claves DNSSEC pueden cumplir esos requisitos con Cloudflare Foundation DNS.

Análisis de DNS basados en GraphQL

Para aquellos que no estén familiarizados con GraphQL, es un lenguaje de consulta para API y un entorno de ejecución para esas consultas. Con GraphQL, los clientes pueden solicitar exactamente lo que necesitan, ni más ni menos, y agregar datos de varias fuentes mediante una única llamada API. También admite actualizaciones en tiempo real mediante suscripciones.

Como sabrás, ya hace un tiempo que Cloudflare tiene una API GraphQL. Sin embargo, como parte de Foundation DNS estamos añadiendo un nuevo conjunto de datos DNS a esa API que solo está disponible con nuestros nuevos servidores de nombres avanzados de Foundation DNS.

El nuevo conjunto de datos de DNS en nuestra API GraphQL se puede utilizar para obtener información sobre las consultas de DNS que ha recibido una zona. Esta alternativa más rápida y eficaz a nuestra API de análisis de DNS actual te permite consultar datos de grandes periodos de tiempo de forma rápida y eficaz, sin límites ni tiempo de espera. La API GraphQL es más flexible con respecto a las consultas que acepta, y expone más información que la API de análisis de DNS.

Por ejemplo, puedes ejecutar esta consulta para obtener el tiempo de procesamiento medio y el percentil 90 de tus consultas, agrupadas por dirección IP de origen, en buckets de 15 minutos. Una consulta de este tipo sería útil para comprobar qué direcciones IP consultan tus registros con más frecuencia durante un intervalo de tiempo determinado:

{
  "query": "{
    viewer {
      zones(filter: { zoneTag: $zoneTag }) {
        dnsAnalyticsAdaptiveGroups(
          filter: $filter
          limit: 10
          orderBy: [datetime_ASC]
        ) {
          avg {
            processingTimeUs
          }
          quantiles {
            processingTimeUsP90
          }
          dimensions {
            datetimeFifteenMinutes
            sourceIP
          }
        }
      }
    }
  }",
  "variables": {
    "zoneTag": "<zone-tag>",
    "filter": {
      "datetime_geq": "2024-05-01T00:00:00Z",
      "datetime_leq": "2024-06-01T00:00:00Z"
    }
  }
}

Anteriormente, una consulta de este tipo no habría sido posible por varias razones. En primer lugar, hemos añadido nuevos campos como sourceIP, que nos permite filtrar los datos en función de las direcciones IP del cliente (normalmente solucionadores) que realizan consultas de DNS. En segundo lugar, la consulta de la API GraphQL puede procesar y devolver datos de rangos de tiempo mucho mayores. Anteriormente, un zona DNS con una cantidad suficientemente grande de consultas solo podía consultar el tráfico correspondiente a algunos días, mientras que la nueva API GraphQL puede proporcionar datos correspondientes a un periodo de hasta 31 días. Tenemos previstas nuevas mejoras de este intervalo de tiempo, así como de la capacidad de almacenamiento y consulta de los datos históricos.

La API GraphQL también nos permite añadir una nueva sección de análisis de DNS al panel de control de Cloudflare. Los clientes podrán realizar un seguimiento de los registros más consultados, ver qué centros de datos responden a esas consultas y cuántas consultas se realizan y mucho más.

El nuevo conjunto de datos de DNS en nuestra API GraphQL y la nueva página de análisis de DNS trabajan juntos para ayudar a nuestros clientes de DNS a supervisar, analizar y solucionar los problemas de sus implementaciones de Foundation DNS.

Nuevo proceso de lanzamiento

El producto de DNS autoritativo de Cloudflare recibe actualizaciones de software aproximadamente una vez a la semana. Cloudflare cuenta con un sofisticado proceso de lanzamiento que ayuda a evitar que las regresiones afecten al tráfico de producción. Aunque no es habitual, es posible que los problemas surjan solo una vez que la nueva versión esté sujeta al volumen y la singularidad del tráfico de producción.

Debido a que nuestros clientes del plan Enterprise desean estabilidad (incluso más que nuevas funciones), las nuevas versiones estarán sujetas a un periodo de inmersión de dos semanas con nuestros servidores de nombres estándar antes de que se actualicen nuestros servidores de nombres avanzados de Foundation DNS. Si no surgen problemas durante ese periodo, los servidores de nombres avanzados de Foundation DNS también se actualizarán.

Las zonas que utilizan servidores de nombres avanzados de Foundation DNS se beneficiarán de una mayor fiabilidad, ya que están mejor protegidas contra las regresiones en las nuevas versiones de software.

Precios de DNS más sencillos

Históricamente, las tarifas del DNS autoritativo de Cloudflare dependían del número de consultas de DNS realizadas al mes y del número de dominios de la cuenta. Nuestros clientes de DNS del plan Enterprise suelen estar interesados en las zonas DNS exclusivas, que son zonas DNS alojadas en Cloudflare que no utilizan nuestros servicios de proxy inverso (capa de aplicación), como nuestras funciones de CDN, WAF o gestión de bots. Con Foundation DNS, simplificamos los precios para la gran mayoría de esos clientes al incluir 10 000 dominios DNS exclusivos por defecto. Este cambio significa que la mayoría de los clientes solo pagarán por el número de consultas de DNS que utilicen.

También incluimos 1 millón de registros DNS en todos los dominios de una cuenta. Sin embargo, eso no significa que no podamos admitir más. De hecho, la zona individual más grande de nuestra plataforma tiene más de 3,9 millones de registros, mientras que nuestra cuenta DNS más grande alcanza apenas los 30 millones de registros DNS distribuidos en varias zonas. Con el DNS de Cloudflare, puedes gestionar sin problemas incluso las implementaciones más grandes.

Todavía queda mucho por llegar

Apenas estamos empezando. En el futuro, añadiremos más funciones exclusivas a Foundation DNS. Por ejemplo, una función muy solicitada: tokens API y permisos de usuario con ámbito de registro. Esto te permitirá configurar los permisos a un nivel aún más granular. Por ejemplo, podrías especificar que un miembro concreto de tu cuenta solo pueda crear y gestionar registros de tipo TXT y MX, para que no pueda eliminar o editar accidentalmente registros de direcciones que pudieran afectar al tráfico web a tu dominio. Otro ejemplo sería especificar permisos en función del subdominio a fin de restringir aún más el alcance de usuarios específicos.

Si ya eres cliente del plan Enterprise y quieres utilizar Foundation DNS, ponte en contacto con tu equipo de cuenta para que suministren Foundation DNS en tu cuenta.