colima fails to resolve some domains (max entries 16?)

[nobletrout]

Describe the Issue

Some domains return a Parse error on nslookup on the colima ssh server, this in turn ends up creating an NX domain on the guest.

colima:~$ nslookup pubsub.googleapis.com
Server:		192.168.107.1
Address:	192.168.107.1:53

Non-authoritative answer:

Non-authoritative answer:
*** Can't find pubsub.googleapis.com: Parse error

colima:~$

This impacts guest machines as well, using dig on a guest machine works, but not the native resolver or nslookup.

Colima Version:

What is the output of colima version

colima version v0.4.2
git commit: f112f336d05926d62eb6134ee3d00f206560493b

runtime: docker
arch: x86_64
client: v20.10.16
server: v20.10.14

Lima Version:

What is the output of limactl --version

$limactl --version
limactl version 0.11.0

Qemu Version

What is the output of qemu-img --version

qemu-img version 7.0.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers

Operating System

• [X] macOS Intel
• [ ] macOS m1
• [ ] Linux

To Reproduce

Steps to reproduce the behavior:

1. use the compose file below, run docker-compose up
2. docker exec into host
3. apt-get update && apt-get install dns-utils
4. nslookup pubsub.googleapis.com . Do a control check with nslookup slashdot.org

docker-compose.yml

version: "3.9"
services:
  web:
    image: "debian"
    entrypoint: ["sleep","10000"]

Expected behavior

The hostname should resolve.

Additional context

It looks like it impacts hosts that have 16 response entries in them.

[jandubois]

It looks like it impacts hosts that have 16 response entries in them.

This may be a bug in the host resolver: it always truncates responses to fit into a 512 bytes UDP packet, even if the request if redone over TCP. We found this in Rancher Desktop for Windows testing, and will upstream the required changes to Lima soon.

As a workaround you may want to disable the host resolver until the fix has been released (as long as you don't need to resolve names over VPN).

[nobletrout]

This sounds like what might be happening. How do I disable the host resolver?

[nobletrout]

Looks like I've got a workaround for now (less than ideal, but works for my particular needs for devtest):

added an explicit nameserver to use in docker-compose.yml file:

dns: 8.8.8.8

https://docs.docker.com/compose/compose-file/#dns

[tekNorah]

I also experienced this issue when attempting to run ddev pull pantheon, which runs terminus backup:get ${project} --element=db --to=db.sql.gz via DDev's db_pull_command, which fails on attempt to reach storage.googleapis.com.

Solve was to change the following line(s) in ~/.colima/default/colima.yaml

from:

   dns: []

to:

  dns:
    - 1.1.1.1

credit: @rfay related: https://github.com/drud/ddev/issues/4035

[deviantintegral]

We just ran into this ourselves. There was an older similar issue fixed in lima-vm in 2021. Perhaps there's been a regression at some point? Or, Google's DNS records are changing size over time.

https://github.com/lima-vm/lima/issues/380

I ended up putting this in ~/.colima/_templates/default.yaml as well so it takes effect when I rebuild colima.