Tag Info

Hot answers tagged

19

SEE UPDATE BELOW! I also enjoy using Dnsmasq on my local machine, and I had this problem too. Here is the solution: From man 5 resolver: The configuration for a particular client may be read from a file having the format described in this man page. These are at present located by the system in the /etc/resolv.conf file and in the files found in the ...


12

IMHO This sounds like you need mysqld to stop using DNS. Please do the following: Add this to /etc/my.cnf [mysqld] skip-host-cache skip-name-resolve Them restart mysql. From then on, mysql will no longer resolve addresses via DNS. Give it a Try !!! CAVEAT Please read these options in the MySQL Documentation: skip-host-cache skip-name-resolve DNS ...


8

This is working as designed. Preferring IPv6 over IPv4 is the default configuration for most computers. To use IPv4 instead of IPv6, the computer must be specifically set up for this (varies by OS). If you want specific hostnames to be inaccessible via IPv6, then you'll have to remove the wildcard CNAME and use records only for the specific hosts you want ...


6

The default behavior for resolv.conf and the resolver is to try the servers in the order listed. The resolver will only try the next nameserver if the first nameserver times out. The resolv.conf manpage says: nameserver Name server IP address Internet address (in dot notation) of a name server that the resolver should query. Up to MAXNS ...


5

There isn't an existing DHCP option for this, so you have to add custom configuration to both the server and clients in order to support this. On the server (/etc/dhcp/dhcpd.conf), define a new option and set the value: option resolv-options code 224 = text; option resolv-options "timeout:2 attempts:4"; On the client (/etc/dhcp/dhclient.conf), define the ...


5

The right way to do this these days is, I believe, to add the DNS information to your /etc/conf.d/net file, so that the rc scripts manage your /etc/resolv.conf file correctly. Add: dns_servers="8.8.8.8 8.8.4.4" to that file and you should be good to go. If you need other resolver settings, look at the net.example file in /usr/share/doc/openrc-*/. Some of ...


5

It's likely that the default timeout is too long and that apps are breaking as a result. Keep in mind that the resolver will go start with the first entry in /etc/resolv.conf -every- time it's called (notwithstanding cached entries). Try adding something like "options timeout:.5" or similar (see the man page - http://linux.die.net/man/5/resolv.conf) to ...


5

There's a hint about this on http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch06_01.htm: In other words, an instance of the resolver still queries the first name server in resolv.conf first, but for the next domain name it looks up, it queries the second name server first, and so on. Note that many programs can't take advantage of this since most ...


5

Is the machine sourcing it's IP address from DHCP? If so, resolv.conf will be turned over by the DHCP client, to reflect the details in the lease it receives. Take a look at the manpage for the DHCP client you are using. For instance dhcpcd has a -R flag which prevents this behaviour.


5

Ahhhh....it doesn't really work that way. As long as the first nameserver is running and active all bind requests will go to it. The only way that you get to the second nameserver is if the previous nameserver in the list has died and after a LONG timeout. To fix your problem, I'm guessing that you might have to build a local caching DNS server ...


4

It's hard to answer clearly as I don't know what you're trying to accomplish: Do you want to manage a private DNS zone using your own BIND server? Do you just want to get DNS resolution working properly? Are you trying to set up a local cache for performance reasons? If you're going to run a local DNS resolver on your server, you would point ...


4

Most applications intialize the resolver once, at startup (with res_init), and never do it again afterwards. It is not a problem for short-life applications like ping but more serious for long-running daemons. The Apache process (which runs mod_php) was probably in that case. Restarting Apache would have suffice.


4

The configuration file is one of /etc/dhcp/dhclient-${DEVICE}.conf, /etc/dhclient-${DEVICE}.conf, or /etc/dhcp/dhclient.conf in that order. The first one that exists is used. From /etc/sysconfig/network-scripts/ifup-eth (Fedora 14; RHEL6 may be similar): # allow users to use generic '/etc/dhcp/dhclient.conf' (as documented in manpage!) # if per-device file ...


4

This behavior is by design. IPv6 is being preferred - so the status of the resource in AAAA terms is determined first. An NXDOMAIN response comes back - so the client figures it needs to append the search path. Note that the ndots remark you've made is correct - but not the whole story. If the ndots number higher than the name being queried (if it were a ...


4

Why are the DNS servers becoming unavailable? That's the issue we should focus on fixing... You should omit the rotate directive if you want to have a deterministic retry order. rotate basically gives you round-robin lookups, which can have undesirable results in your situation. My DNS /etc/resolv.conf tends to look like: search blah.net client.blah.net ...


4

That's easy to discover. Just run: rpm -qf /etc/resolv.conf You will see the answer is: file /etc/resolv.conf is not owned by any package That's because it's generated by the system at installation time, and later managed by the sysadmin (that is hopefully you) or NetworkManager.


4

You can't easily do what you want. Or how do I configure a different DNS Name Server for eth0 vs eth1? The name lookup for a hostname happens through standard system libraries and isn't associated in any way with a particular "connection". In fact, at the time the DNS query happens, there is no connection, because your application hasn't even ...


3

DNS resolvers can be added in OS X via the networksetup command: sudo networksetup -setdnsservers Wi-Fi 8.8.8.8 8.8.4.4 Insert name of network connection as appropriate. These resolvers will appear in resolv.conf as it is automatically generated, but direct edits to resolv.conf will not result in those resolvers being used. I assume the resolvers are ...


3

/etc/resolv.conf is the system-wide configuration of where to look for DNS, as used by gethostbyname() etc. http://linux.die.net/man/5/resolv.conf It is generally overwritten by the network service with the adapter-specific settings given in ifcfg (or provided by DHCP). So any changes to preferred DNS servers should be made in the ifcfg files rather than ...


3

It is better to ask a more deterministic question. What do you mean by very slow? The server overall performance is bad or some specific services are not responding as expected?? Yes, the DNS issues can result in some performance problems. How to fix the issue: Configure your server to use a proper DNS server. At least, you can configure an internal one ...


3

to prevent dhcp client rewriting your settings you can put as well in dhclient.conf [ /etc/dhcp3 in debian, if you use isc's dhcp3-client ] supersede domain-name "your.domain.name"; supersede domain-name-servers 127.0.0.1, 192.168.1.108 ; this might look differently for other dhcp clients.


3

No, this is not possible. However, you can use what is called split DNS. Install a DNS server and configure it to do recursive queries, using the DNS servers provided by your ISP as forwarders. This ensures that all names that can be resolved on the Internet, will be resolved. Update your DHCP server so that it hands out the IP address of this name server ...


2

What this means is that one of your DNS resolvers isn't working. You can probably just swap in OpenDNS/install your own nameserver. The 'search' line is a domain that's appended to names you lookup. So, if you have search google.com in your resolv.conf, and you try to go to 'mail' you'll end up at 'mail.google.com'. It's not necessary, but is ...


2

Have you tried installing your own local caching named? Install BIND locally (caching only), and then let it query the DNS the way it was meant to (find delegations dynamically based on delegations). The just change resolv.conf to point to 127.0.0.1 and be done with it. Maybe throw one of your hosts IPs in there as a backup, but mostly rely on your own ...


2

On Debian based systems there is a package resolvconf (wiki) that is designed to handle updating of the resolv.conf. You can append, or delete entries. You can setup scripts that will be called whenever an update has happened. This allows you to notify other services that an update has been made.


2

You are probably using DHCP for automatic IP configuration. Best option to try: /etc/dhclient.conf or /etc/dhcp/dhclient.conf file contains configuration information for dhclient. You can toggle the DNS updates/ point to different DNS server from this file. The man pages for DHCLIENT.CONF and DHCP-OPTIONS point out that in dhclient.conf, you should ...


2

resolv.conf directs resolvers on where to look for names. In most cases, this is going to be the libc resolver, but there may be other cases such as vPostMaster which uses the Python DNS resolver library for SPF lookups. So, it COULD be that the resolver is caching the resolv.conf information for long-running processes, but it sounded like you restarted ...


2

Check that you have a fully qualified name (dev-kranichs.domain.something) for 127.0.0.1 in your /etc/hosts. You should have a line looking similar to 127.0.0.1 dev-kranichs.domain.something dev-kranichs 127.0.0.1 dev-kranichs.local dev-kranichs could be enough.


2

From man resolv.conf: domain Local domain name. Most queries for names within this domain can use short names relative to the local domain. If no domain entry is present, the domain is determined from the local hostname returned by gethostname(2); the domain part is taken to be everything after the first '.'. Finally, if the hostname ...



Only top voted, non community-wiki answers of a minimum length are eligible