Is there a good API alternative to res_ninit?
There are problems with this call because the res->_u.ext.nscount6 and res->nscount do not reflect correct numbers. Adding a IPv6 address to /etc/resolv.conf still results in the nscount increasing where you would have expected the nscount6 to increase.
An older glibc version seems to increase both nscount and nscount6 for a IPv6 address in /etc/resolv.conf.
I am currently parsing resolv.conf directly because i am unable to depend on the res_ninit call. But this is fine for Manual DNS.
When it comes to DHCP DNS, then i need an API to give me the result. There is no other way (that i can think of) to determine the DNS IP addresses over DHCP.
Tried posting in other places within the board but not of help so far. E.g.
Retrieve IPv4 and IPv6 nameservers programmatically
res_ninit and res_init only ever read name server information from /etc/resolv.conf. You can always get the same data name servers by parsing /etc/resolv.conf yourself and examining the nameserver lines. If there is no nameserver line, the default 127.0.0.1 will be used.
I don't think it is necessary to provide an API for that because the file format is so simple that is likely more difficult to use the API than to read the file instead.
Name server assignment over DHCP is implemented by rewriting /etc/resolv.conf if there is no local caching resolver running on the machine. The exact mechanism used for that is distribution-specific, e.g. Debian uses resolvconf if it is installed.
If a local caching resolver is running on the system (such as dnsmasq or Unbound), name servers over DHCP can be directly configured in that caching resolver. In this case, /etc/resolv.conf will keep pointing to the same name server, typically by listing nameserver 127.0.0.1 or no name server information at all (which is the default).
Related
Now that we have a dynamic DNS resolving Backend with Haproxy 1.6, i've been wondering whether I can make resolving to endpoint to dynamic backends. Here's what I would be looking for:
resolvers docker
nameserver dnsmasq 127.0.0.1:53
defaults
mode http
log global
option httplog
frontend f_myapp
bind :443
default_backend b_myapp
backend b_myapp
server services *:443 check resolvers docker resolve-prefer ipv4
OR
server services [%Host]:443 check resolvers docker resolve-prefer ipv4
Having this would allow me not to have to touch haproxy's configuration but only use DNS to update the backend-routing.
Thanks
Alessandro
A server declared in HAProxy is a single destination IP address. Even if that IP address is dynamic and can change, as is now possible in 1.6, a server is only/always/ever a single destination, not a target that changes with each request. What you are contemplating is not consistent with the design of HAProxy.
Your back-end servers must be declared in advance. You can create dummies and modify them via the stats socket, and dynamic configuration can be accomplished by scripting the configuration-file-generating process (using external tools) and then reloading HAProxy but... it has no internal concept matching what you are contemplating.
Additionally, of course, even if it did, is a problem with your plan -- it represents a potential security hole: if HAProxy were to interpret %[Host] (which I assume refers to %[req.hdr(host)]) as an IP address, no resolution would be needed and you've just given internal access to anyone who passed an IP address in the Host header.
I'm looking for a way of getting our DNS server to do a reverse look-up in order to resolve placeholder values differently according to the requesting machine's IP address.
Variables
A placeholder value called SYSWEB to be resolved by DNS
Websites: www.website.dev.net and www.website.uat.net
Machines: Machine1 and Machine2
Conditions
If Machine1 attempts to connect to SYSWEB, the DNS server will
resolve it to www.website.dev.net
If Machine2 attempts to connect to SYSWEB, the DNS server will
resolve it to www.website.uat.net
I've already tried to do this with BIND DNS, following the implementation laid out here, but I have not made any progress worth noting....
The main problem I'm having is that I cannot allow the DNS to resolve an IP address from the placeholder value, it needs to be a domain name.
Surely someone out there has successfully done what I'm failing to do
You need to have two separate zone files and route access to the correct zone file based on views. This is usually called split-horizon DNS and there are plenty of examples on the net, e.g.
http://www.zytrax.com/books/dns/ch6/#split-view
http://www.knowplace.org/pages/howtos/split_view_with_bind_9_howto.php
So, I'm on day 3...
I am running an Ubuntu.64-based distribution on a VirtualBox. I have the need to access both external ISP DNS servers, as well as "internal" DNS servers through an OpenVPN connection. At times I need to query the external DNS(#host example.com) through the eth0 interface; sometimes I need to query the VPN "internal" DNS (#host internal.local) through the tap0 interface.
My question is: how do I configure my system to query the correct nameserver-- the ISP DNS or the VPN DNS (for attempting zone transfers, for example)?
I've tried editing resolv.conf to include both external and internal nameservers/domains, with no luck (obviously). I've also tried mitigating the situation with dnsmasq. That got me close (I think).
I realize I can use dig to set the [#server] based on individual queries, but I would appreciate a systemic resolution.
Any help would be appreciated.
I've used the PowerDNS recursor for exactly this situation before; it is in the package pdns-recursor, if you wish to try it. You'll want to set your /etc/resolv.conf to query only 127.0.0.1 should you choose to try this approach.
The forward-zones directive lets you specify which servers to contact for which zones:
forward-zones= ds9a.nl=213.244.168.210, powerdns.com=127.0.0.1
It does look a little strange, since it is one configuration setting that takes multiple values, but you do get to specify exactly which servers are going to provide answers for which domains.
Our application (RHEL 5/c++) uses the hostid as returned by gethostid for logging purposes. For some reason, the primary DNS server of the local network environment went offline. This resulted in massive problems in gethostid: The function call hangs for more than 60s, which lead to internal timeouts in our application. A call to hostid on the commandline also didn't return after several minutes. Once the DNS server was up again, the timeouts/problems both in the application and the hostid commandline tool disappeared.
My question is: How do I prevent gethostid from making DNS lookups? There`re some boundary conditions to the answer:
The file /etc/hostid must not exist.
Calling sethostid is not allowed.
Changing /etc/hosts is not possible.
I'm astonished this happens at all. As I understand gethostid it works like this:
Return the value of the last sethostid if it has been set manually.
Return hostid form /etc/hostid if the file exists.
Return the primary IP of the host if set.
Fail for other cases.
I don`t see the need for a DNS query.
To verify, that gethostid actually is dependend on a working DNS server, try this:
As root create/change your /etc/reslov.conf so it contains only invalid nameserver entries.
Call hostid on the commandline.
On my debian/squeeze installation this results in a hostid of 00000000 without any hangs. I assume the RedHat-version of hostid is different/older and results hangs.
I think preventing DNS lookups from gethostid is not really possible without breaking the system or violating one of the boundary conditions. On gnu.org I've found this comment on the sethostid function:
The proper way to establish the primary IP address of a system is to configure the IP address resolver to associate that IP address with the system's host name as returned by gethostname. For example, put a record for the system in /etc/hosts.
From this I conclude, that gethostid determines the IP like this:
Get the hostname from gethostname.
Determine the IP via gethostbyname (or a similar method).
Under the conditions, that the host name is not associated to an IP address in /etc/hosts and /etc/nsswitch.conf allows DNS lookups, a DNS lookup will be made by gethostid.
Our user interface is communicating with another application on a different machine, often connecting using domain names.
On our network, when IPv6 is installed, DNS name resolution works great, all machines can be pinged and contacted fine.
When IPv6 is uninstalled, pinging the same DNS names returns an IP address on some distant subnet (24.28.193.9; local subnet is 192.168.1.1); our application is then unable to communicate. When IPv6 is reinstalled, the DNS resolution corrects itself.
Even without IPv6 when ping is not working, I can still browse other machines using Windows Explorer by entering \\\\MACHINE_NAME\\. I'm not sure why the name resolution seems to work here. We are working in the Windows XP SP2 environment.
The IPs of the machines can be pinged successfully. It is only the DNS names that do not resolve properly.
I looked for the address of our DNS server. All of our computers are pointing at the network gateway, which is a wireless router. The router has the same DNS server address listed when IPv6 is installed as it does when it isn't installed.
The strangest thing is that I just discovered that it does not matter what DNS name I ping. All pings to DNS names return the same address: "24.28.193.9".
I tried flushing the DNS Resolver Cache and registering DNS on the target machine and the source machine. All to no avail. The only DNS name that I can ping is the name of the current machine.
Any thoughts as to why our software can't communicate without IPv6 installed?
UPDATE:
OK, I've done a little more research now.
I looked for the address of our DNS server. All of our computers are pointing at the network gateway, which is a wireless router. The router has the same DNS server address listed when IPv6 is installed as it does when it isn't installed.
The strangest thing is that I just discovered that it does not matter what DNS name I ping. All pings to DNS names return the same address: "24.28.193.9".
I tried flushing the DNS Resolver Cache and registering DNS on the target machine and the source machine. All to no avail. The only DNS name that I can ping is the name of the current machine.
Any other suggestions? Thanks so much for your help.
You've got multiple things going on here
DNS Name resolution
Windows Name resolution
IP-IP ICMP communication
You've written your question as if there's a problem with #3, but everything you describe points to the problem actually being with #1. If you take resolution out of the question, can you ping the correct IPs with our without IPv6 installed?
It sounds like maybe you have an IPv6 name server installed that has correct information and the IPv4 name server is incorrect? Are you receiving name servers via DHCP or hard coding? What are the IPs of the name servers you are using when IPv6 is installed and when it isn't?
I know this is a late answer, but in case someone else has the same problem, the key is the IP address, "24.28.193.9". A quick Google search reveals it seems to be related to your ISP completely breaking the DNS protocol by returning a fixed IP address for all non-existent domain names (the correct answer would be NXDOMAIN). Your network gateway is most probably just forwarding your queries to your ISP's name servers.
Your systems are relying on the correct operation of the DNS protocol. They are expecting a NXDOMAIN answer before querying the name via other methods (most probably NetBIOS name resolution). Since the DNS server is completely broken and returning an incorrect answer, the correct address is never looked up.
The reason installing or uninstalling IPv6 changes the situation is most probably because something related to it is changing the name resolution order (to look up using other methods before trying DNS). So, a workaround would be to change the name resolution order yourself.
The real fix would be to either change to a better ISP (one which does not break established protocols) or run your own DNS server (which is what I started doing on all systems I administer ever since VeriSign pulled a similar stunt; theirs was even worse in that changing ISPs made no difference at all).
References:
Warning: Road Runner DNS says nonexistent domains exist