Se usó la API de Cloud Translation para traducir esta página.

API de ResourceRecordSets de Cloud DNS

1. Introducción

Última actualización: 6/1/2021

¿Qué es Cloud DNS?

Qué compilarás

En este codelab, crearás una zona administrada de Cloud DNS y recursos ResourceRecordSets relevantes con gcloud para administrar la resolución de nombres en alguna instancia de VM.

Qué aprenderás

Cómo CREATE, READ, DELETE y UPDATE individuales ResourceRecordSets

Requisitos

2. Cómo prepararte

Configura tu proyecto de Google Cloud Platform

Acceder a gcloud

gcloud auth login

Crea un proyecto

gcloud projects create my-codelab-project

Habilita la API de Cloud DNS

gcloud services enable dns.googleapis.com

Es posible que el cambio demore unos minutos en aplicarse

3. Crea una zona administrada privada

Una ManagedZone contiene ResourceRecordSets.

Toma nota del nombre de dominio para el que quieres agregar registros DNS. En este ejemplo, usaremos “mi-dominio.com” y supón que tu instancia de VM está en la red predeterminada.

gcloud dns managed-zones create my-zone \
    --description="ManagedZone for Cloud DNS ResourceRecordSets codelab." \
    --dns-name=my-domain.com. \
    --networks=default \
    --visibility=private

4. Administrar ResourceRecordSets

Al final de esta sección, las solicitudes de DNS a través de tu red privada virtual para tu dominio se resolverán en la dirección IP de la VM.

Por ejemplo, si la dirección IP de tu VM es “1.2.3.4” y quisieras “my-domain.com”. para resolverse en esa dirección IP, debes crear un “registro A”.

CREAR un registro A

gcloud dns record-sets create "my-domain.com." --type="A" --ttl="60" --rrdatas="1.2.3.4" --zone="my-zone"

El argumento posicional "my-domain.com". , también conocido como dnsName, es el nombre para el que queremos definir la resolución de DNS.
–type: Denota el tipo de registro DNS que intentamos crear.
–ttl: denota el tiempo de actividad para este registro.
–rrdatas: Contiene la respuesta real de la consulta.
–zone: Se requiere para indicar en qué ManagedZone se debe crear este registro.

Obtén más información sobre los conceptos de DNS aquí.

Ahora que creaste el registro A, deberías poder probar la resolución de DNS.

Establece una conexión SSH a tu máquina. En este ejemplo, usamos una instancia de VM con el nombre "dns-codelab" en “us-central1-a”

gcloud compute ssh codelab --zone=us-central1-a

Instala dnsutils para poder usar “dig” comando

sudo apt install dnsutils

buscar su dominio

dig my-domain.com.

esto debería producir un resultado similar al

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19979
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;my-domain.com.                        IN        A

;; ANSWER SECTION:
my-domain.com.                60        IN        A        1.2.3.4
...

CREATE, PATCH y GET un registro CNAME

Ahora que asignaste mi-dominio.com. a 1.2.3.4, deberías asegurarte de que www.mi-dominio.com. también resuelve a 1.2.3.4. Registros para "www." no se crean automáticamente.

Si consultas www.mi-dominio.com

dig www.my-domain.com.

obtendrás un resultado similar al siguiente

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

indica que no hay registro DNS para ese dominio

En lugar de crear otro registro A, debemos crear un registro CNAME que sea un indicador de otro registro. Esto evitará que tengamos que cambiar ambos registros en caso de que queramos usar una dirección IP diferente.

Sal de tu instancia de VM

exit

Crear registro CNAME

gcloud dns record-sets create "www.my-domain.com." --type="CNAME" --ttl="60" --rrdatas="my-domin.com." --zone="my-zone"

Ahora que creaste tu registro CNAME, deberías poder probar la resolución de DNS.

Vuelve a establecer una conexión SSH a tu máquina

gcloud compute ssh codelab --zone=us-central1-a

buscar su dominio

dig www.my-domain.com.

deberías haber recibido un resultado similar al

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61964
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...

¡Ay, no! Parece que se produjo un error tipográfico al crear el registro CNAME en “–rrdatas” marca. En lugar de borrar y volver a crear el registro, podemos aplicar un parche en el cambio correcto.

sal de tu instancia de VM

exit

Aplicar un parche al registro CNAME

gcloud dns record-sets update "www.my-domain.com." --type="CNAME" --rrdatas="my-domain.com." --zone="my-zone"

Ten en cuenta que podemos omitir “–ttl” marca, ya que no la cambiaremos, pero todas las demás marcas se deben incluir, ya que forman parte del identificador único universal de ResourceRecordSet.

También podemos verificar que el registro sea el esperado con gcloud

gcloud dns record-sets describe "www.my-domain.com." --type="CNAME" --zone="my-zone"

lo que debería producir resultados

NAME                    TYPE    TTL  DATA
www.my-domain.com.      CNAME   60  "my-domain.com."

verificar que el registro CNAME se esté resolviendo correctamente

gcloud compute ssh codelab --zone=us-central1-a

dig www.my-domain.com.

deberías haber recibido un resultado similar al

...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7471
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
...
;; QUESTION SECTION:
;www.my-domain.com.                IN        A

;; ANSWER SECTION:
www.my-domain.com.        60        IN        CNAME         my-domain.com..
...

BORRAR para limpiar

Antes de que se pueda borrar una ManagedZone, primero se deben borrar todos los ResourceRecordSets dentro de ManagedZone (excepto los registros NS y SOA, que se generan automáticamente y deben existir siempre en ManagedZone).