Почему был бы 127.0.0.1 в проблемах причины resolv.conf в разрешении DNS?

[обновление и обновление II: посмотрите мои неловкие и надлежащие решения в конце вопроса, на основе одного из ответов]

У меня есть чрезвычайно медленный поиск DNS, когда мой resolv.conf файл включает 127.0.0.1 IP-адреса, на самом деле, много имен не становятся разрешенными вообще, поскольку он (несомненно) испытывает таймаут.

Я нашел один вопрос с тем, что похоже на действительный ответ здесь:

Extrememly замедляют поиск DNS

за исключением того, что я вижу, dnsmasq инструмент работает за диапазоном IP 192.168.122.2 к 192.168.122.254. Это похоже на дюйм/с, используемого VirtualBox и qemu, таким образом, я предположу, что, если я выключаю dnsmasq, получая доступ к Интернету от виртуальной системы, перестанет работать!

Была бы другая причина замедления и/или тайм-аута? (обратите внимание, что проблема является более видной с определенными системами, такими как пользовательскые изображения на всех stackoverflow веб-сайтах, включая askubuntu, когда проблема происходит.)

В этой точке я удаляю IP из resolv.conf файла, и это обходит проблему, в то время как я просматриваю, но я не думаю, что это - лучшее решение (и конечно что IP переустанавливается там на каждой перезагрузке!) я хотел бы более постоянное решение этой проблемы, которая все еще позволяет мне выполнять виртуальные системы как ожидалось.

P.S. Я не выполняю Администратора сети.

Содержание/etc/network/interfaces

Обратите внимание, что у меня была проблема прежде, чем добавить 2-й IP на eth1 (т.е. eth1:0).

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth1
iface eth1 inet static
    address 162.226.130.121
    netmask 255.255.255.248
    network 162.226.130.120
    broadcast 162.226.130.127
    gateway 162.226.130.126

auto eth1:0
iface eth1:0 inet static
    name Local network
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.254

# bridge for virtual box
auto br0
iface br0 inet static
    address 192.168.2.1
    netmask 255.255.255.0
    network 192.168.2.0
    broadcast 192.168.2.255
    bridge_ports    eth3
    bridge_stp      off
    bridge_maxwait  0
    bridge_fd       0

Содержание/etc/resolv.conf (который является все еще гибкой ссылкой как ожидалось) после начальной загрузки:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search m2osw.com
nameserver 192.168.122.1
nameserver 206.13.31.12
nameserver 206.13.28.12

Обновление:

Я не пишу ответ сам, потому что я очень использовал другой ответ здесь для решения моего вопроса, хотя это действительно не, что я хотел сделать, это - самое легкое решение в этой точке. Ошибка, на которую ссылается resolvconf автор ниже, найденная здесь:

https://bugs.launchpad.net/ubuntu / + source/bind9 / + ошибка/933723

ясно состояния, что, если Вы хотите использовать bind9, Вы получите пространство имен 127.0.0.1 в своем resolv.conf файле. Никакой выбор. (RESOLVCONF=no, кажется, ничего не делает, хотя у меня может быть удивление после перезагрузки, которую я сделаю очень скоро!)

Как примечание стороны: Если я указываю на/etc/resolvconf/resolv.conf.d/tail softlink на/dev/null (как упомянуто ниже) затем, я получаю resolv.conf, который похож на это:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1

Другими словами, я все еще получаю 127.0.0.1, который является преступником в этой точке. Но также и я полностью теряю другие два сервера имен, даже при том, что они ясно указаны в моем интерфейсе eth1. Это сказанное, смотря в/run/resolvconf/interface/каталоге, я вижу eth1.net и lo.named файлы. lo.named копируется в resolv.conf, но не eth1.net. У меня нет подсказки, как те файлы создаются и затем скопировали в resolv.conf, но это - динамизм, используемый resolvconf...

Так или иначе существует два решения, упомянутые в ошибке:

(1) Удалите/etc/resolv.conf гибкую ссылку и замените ее простым файлом с точно, что Вы хотите. Это может работать на Вас, но я думал, что хранение динамического файла по умолчанию будет лучшим.

(2) Измените свои bind9 настройки, таким образом, BIND может ответить на те локальные запросы DNS. Интересная вещь с этим состоит в том, что имена будут теперь кэшироваться на Вашем компьютере. Таким образом, это не все плохо. Это сказанное, я не также интересовался открытием моего сервера имен ко всем доменным именам... Но это работает, и я не должен уничтожать динамический resolv.conf.

На всякий случай существует установка в качестве примера для связывания, чтобы заставить это работать:

options {
    [...]
    forwarders {
          // Google DNSes
          8.8.8.8;
          8.8.4.4;
    };
    [...]
};

Обновление II:

Хорошо! Перезагрузка избавилась от lo.named файла в/run/resolvconf/interface каталоге. Это должно быть то, потому что связывают, знает для создания его, если RESOLVCONF=yes, но это не удаляет его если RESOLVCONF=no. Однако перезагрузка заботится об этом, потому что / запущенный каталог является псевдодиском.

Без того файла в пути/etc/resolv.conf является установкой с точно, что я ожидал бы, который является списком серверов имен, столь же определенных в моем eth1 определении, найденном в/etc/network/interface как показано ранее.

Так... это - большая путаница, потому что существует много факторов, и в некоторых случаях перезагрузка требуется!