1. Introducción
Última actualización: 06/01/2021
¿Qué es Cloud DNS?
Consulta nuestra página principal.
Qué compilarás
En este codelab, crearás una ManagedZone de Cloud DNS y los ResourceRecordSets pertinentes con gcloud para administrar la resolución de nombres en alguna instancia de VM.
Qué aprenderás
Cómo CREAR, LEER, BORRAR y ACTUALIZAR objetos ResourceRecordSet individuales
Requisitos
2. Cómo prepararte
Configura tu proyecto de Google Cloud Platform
Accede 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 tarde unos minutos en aplicarse.
3. Crea un ManagedZone privado
Un objeto ManagedZone contiene objetos ResourceRecordSet.
Toma nota del nombre de dominio para el que deseas agregar registros DNS. En este ejemplo, usaremos "mi-dominio.com" y supondremos 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. Administra 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 deseas que "mi-dominio.com" se resuelva en esa dirección IP, debes crear un "registro A".
CREA 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: Indica el tipo de registro DNS que intentamos crear.
- -ttl: Indica el tiempo de actividad de este registro.
- –rrdatas: Contiene la respuesta real a la búsqueda.
- –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 tu registro A, deberías poder probar la resolución de DNS.
Establece una conexión SSH en 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 el comando "dig".
sudo apt install dnsutils
consultar tu dominio
dig my-domain.com.
Esto debería producir un resultado similar al siguiente:
...
;; 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 my-domain.com a 1.2.3.4, probablemente querrás asegurarte de que www.my-domain.com también se resuelva en 1.2.3.4. Los registros para los prefijos "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
...
lo que indica que no hay un registro DNS para ese dominio
En lugar de crear otro registro A, debemos crear un registro CNAME, que es un puntero a otro registro. Esto evitará que tengamos que cambiar ambos registros en caso de que queramos usar una dirección IP diferente.
salir de tu instancia de VM
exit
Crea un 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
consultar tu dominio
dig www.my-domain.com.
Deberías haber recibido 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
...
¡Ay, no! Parece que hubo un error de escritura cuando creamos nuestro registro CNAME en la marca "–rrdatas". En lugar de borrar y volver a crear el registro, podemos aplicar el cambio correcto.
salir de tu instancia de VM
exit
Aplica 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 la marca "–ttl" ya que no la estamos cambiando, pero se deben incluir todas las demás marcas, 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"
que debería producir el resultado
NAME TYPE TTL DATA
www.my-domain.com. CNAME 60 "my-domain.com."
Verifica que el registro CNAME se resuelva correctamente
gcloud compute ssh codelab --zone=us-central1-a
dig www.my-domain.com.
Deberías haber recibido un resultado similar al siguiente:
...
;; 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 un objeto ManagedZone, primero se deben borrar todos los objetos ResourceRecordSet dentro de él (con la excepción de los registros NS y SOA, que se generan automáticamente y siempre deben existir en el objeto ManagedZone).
salir de tu instancia de VM
exit
Borra el registro CNAME
gcloud dns record-sets delete "www.my-domain.com." --type="CNAME" --zone="my-zone"
Borra el registro A.
gcloud dns record-sets delete "my-domain.com." --type="A" --zone="my-zone"
Borra el objeto ManagedZone
gcloud dns managed-zones delete "my-zone"
5. Felicitaciones
¡Felicitaciones! Aprendiste a administrar tus ResourceRecordSets correctamente.