Google Compute Engine: Internal DNS Server and Resolution Issues

Question

Since the google Compute engine does not provide internal DNS, I created 2 bound machines that will execute permissions for machines on GCE and forward permissions via vpn to my personal cloud and vice versa.

since Google Docs for cloud help suggests using this scenario. and edit resolv.conf for each instance to execute the resolution.

What I did was modify ifcg-eth0 to disable PEERDNS and in /etc/resolv.conf I added a search domain and returned 2 instances of my instances.

now after rebooting one instance .. it does not start again because it is looking for the metadata.google.internal domain

Jul 8 10:17:14 instance-1 google: Waiting for metadata server, attempt 412

What is the best practice in such scenarios?

tee

I also need an internal DNS in order to make a failover from a bad person, since GCE does not provide internal balancers.

Answer 1

As mentioned in https://cloud.google.com/compute/docs/networking :

Each instance metadata server acts as a DNS server. It stores DNS records for all network IP addresses on the local network and calls the Google public DNS server for records outside the network. You cannot configure this DNS server, but you can configure your own DNS server if you want, and configure your instances to use this server by editing the /etc/resolv.conf file.

Thus, you should simply use 169.254.169.254 for your DNS server. If you need to define external DNS records, you may need Cloud DNS . If you configured a domain with cloud-based DNS or any other DNS provider, the resolver 169.254.169.254 should find it.

If you need something more complex, such as internal DNS client names, then your own BIND server might be the best solution. Just make sure metadata.google.internal. Permitted 169.254.169.254.

Answer 2

OK, I just ran to it .. but, unfortunately, after 30 minutes there was no timeout that made it work. Fortunatly nelasx correctly diagnosed and corrected. I add this to give the steps that I had to take based on his beautiful question and commented on the answer. I just gathered the information that I had to gather together to find a solution.

Symptoms: when you start the google instance - refusal was refused After checking the serial console output, you will see:

 Jul 8 10:17:14 instance-1 google: Waiting for metadata server, attempt 412 

You can try to wait, not work for me, and check out https://github.com/GoogleCloudPlatform/compute-image-packages/blob/master/google-startup-scripts/usr/share/google/onboot

 # Failed to resolve host or connect to host. Retry indefinitely. 6|7) sleep 1.0 log "Waiting for metadata server, attempt ${count}" 

He ordered me to believe that this would not work.

So, the solution was to tinker with the disk in order to add nelasx to the solution: "edit ifcfg-eth and change PEERDNS = no edit / etc / resolv.conf and enable over your name servers + change the domain domain / etc / hosts and add: 169.254.169.254 metadata.google.internal "

To do this,

• It is best to back up the snapshot before you start if it goes wrong.

• Uncheck "Delete boot disk when deleting instance" for your instance

• Delete instance

• Create a micro instance

• Install disk

  sudo ls -l / dev / disk / by-id / * # this will give you the instance name

  sudo mkdir / mnt / new

  sudo mount / dev / disk / by-id / scsi-0Google_PersistentDisk_instance-1-part1 / mnt / new

where instance-1 will be modified according to your setup

6. Go into editing according to nelasx's solution - the idiot trap that I fell into - use the relative path - not only sudo vi / etc / hosts use / mnt / new / etc / hosts - it cost me 15 more minutes since I had to go through: got depressed, scratched his head, started kicking himself.

7. Delete the debug instance, make sure that the selected option to delete the connected drive is not checked

8. Create a new instance that matches your original, with the edited disk as the boot disk and run it.