DNS Server Refusing Connection - dns

I am implementing a dns client, in which i try to connect to a local dns server, but the dns server is returning the message with an error code 5 , which means that its refusing the connection.
Any thoughts on why this might be happening ?? Thanks

DNS response error code 5 ("Refused") doesn't mean that the connection to the DNS server is refused.
It means that the DNS server refuses to provide whatever data you asked for, or to do whatever action you asked it to do (for example a dynamic update).
Since you mention a "connection", I assume that you are using TCP?
DNS primarilly uses UDP, and some DNS servers will refuse all requests over TCP.
So the solution might be as simple as switching to UDP.
Otherwise, assuming you are building your own DNS client from scratch, my first guess would be that you are formatting the request incorrectly. Eventhough the DNS protocol seems fairly simple, it is very easy to get this wrong.
Finally, the DNS server may of course simply be configured to refuse requests for whatever you are asking.

explicitly adding the network from which i wanted to allow-recursion fixed this problem for me:
these two lines added to /etc/bind/named.conf.options
recursion yes;
allow-recursion { 10.2.0.0/16; };

Policy enforcement?
The DNS server could be configured to accept only connections from certain hosts.

Hmm, if you're able to access StackOverflow you have a working DNS server SOMEwhere. Try doing
host -v stackoverflow.com
and look for messages like
Received 50 bytes from 192.168.1.1#53 in 75 ms
then pick the address out of that line and use THAT as your DNS - it's obviously willing to talk to you.
If you're on Windows, use NSLOOKUP for the same purpose. Your name server's address will be SOMEwhere in the output.
EDIT:
When I'm stuck for a DNS server, I use the one whose address I can remember most easily: 4.2.2.2 . See how that works for you.

You might try monitoring the conversation using WireShark. It can also decode the packets for you, which might help you determine if your client's packets are correctly encoded. Just filter on port 53 (DNS) to limit the packets captured by the trace.
Also, make sure you're using UDP and not TCP for queries; TCP should be used primarily for zone transfers, not queries.

Related

Discovering a machines default DNS

I'm writing a small DNS proxy. It listens for incoming UDP messages on a port and resolves them using a specified DNS (e.g. google's DNS 8.8.8.8) and sends the response back to the client.
I would like to be able to detect the default DNS a machines uses. Every OS has an option to obtain the DNS server address automatically. I was wondering how this is done. Is there a protocol on top of UDP or TCP, or something else entirely?
I'm using C#, but the language isn't important.
Finding which DNS the current computer uses as default is highly dependent on both which OS you use and which language you use. If you use Java or .NET, or another platform independent language you might not need to worry about the OS bit though.
Client computers usually "auto-discover" which DNS to use in the DHCP response from the DHCP server. That is when they receive their IP address they also get which DNS server to use. They might also get addresses to WINS servers and a multitude of custom options.
You can find the DNS server by typing ipconfig/all in coand prompt. This will gove you the address of your DNS server.

Can't get DNSMASQ DHCP to configure multiple name servers

Perhaps someone has some help? I am running dnsmasq on Ubuntu 12.04 LTS. This server's address is 192.168.15.3. My gateway's DNS is 192.168.1.254, that takes me out to the Internet. I also have a special-purpose DNS at 192.168.15.2. So I wanted to give those 3 name servers to DHCP clients. This is my dnsmasq.conf server= section:
server=/localnet/192.168.15.3
server=/localnet/192.168.15.2
server=/15.168.192.in-addr.arpa/192.168.1.254
However, when I look at the DHCP allocation on a client, I see only 192.168.15.3 as the sole DNS server. Clients cannot access the Internet (the NIC on .3 is configured correctly and can access the Internet from its console login).
Granted, the first server= line is probably not necessary, but I added it thinking it may help, didn't.
What am I doing wrong? Thanks for your help!
OK, after MUCH experimentation, I found I had to push the option manually. In the dnsmasq.conf file, I added the following line:
dhcp-option=6,
like so:
dhcp-option=6,192.168.15.3,192.168.15.2,192.168.1.254
This served the correct list of name servers to DHCP clients.
The server lines are configuration for dnsmasq's own DNS server, about where it should forward DNS requersts that it receives in order to be able to resolve (and cache) them.
Only the dhcp-options are part of the DHCP configuration that get passed to DHCP clients - so, the accepted anser is correct, but I wanted to share why.

Node.js: Disable UDP DNS lookup and use the given IP instead

I have a simple CentOS node.js server that is supposed to consume high frequency UDP messages and then forward them to another service.
Trouble is that dgram.send does a DNS lookup on EVERY call. This DNS lookup is both slowing down the processing of the messages and occasionally getting the DNS server to blacklist the node.js host server thinking it's getting DOS'd.
The question is: how do I send a UDP packet in node.js WITHOUT incurring a DNS lookup?
Thanks for the time.
Glancing through the code for Node, it looks like you can pass an IP address to dgram.send and it won't do anything with DNS. Is it possible to look up or cache your IPs manually and then pass them to the send method?

Using IPv6/IPv4 tunneling to send a query to a DNS server - valid or not

I was wondering what exactly the standards say about using IPv6/IPv4 tunneling to send a DNS query to a DNS server. Is this a valid thing to do? Does anyone know the RFCs (and sections if possible) that talk about this?
Thanks.
Of course it is possible. Once you have a tunnel, you can do it whatever you want, concerning IPv6.
If you tunnel the trafic f a complete network, other PCs maybe don't even know that they are behind a tunnel.
My PC here, for example, has some IPv4 and some IPv6 entries in the /etc/resolv.conf.

Intercept traffic above the transport layer

Firstly, I'm relatively new to network programming. I want to intercept and delay HTTP traffic before it gets to the server application. I've delved into libnetfilter_queue which gives me all the information I need to delay suitably, but at too low a level. I can delay traffic there, but unless I accept the IP datagrams almost immediately (so sending them up the stack when I want to delay them), they will get resent (when no ACK arrives), which isn't what I want.
I don't want or need to have to deal with TCP, just the payloads it delivers. So my question is how do I intercept traffic on a particular port before it reaches its destination, but after TCP has acknowledged and checked it?
Thanks
Edit: Hopefully it's obvious from the tag and libnetfilter_queue - this is for Linux
Hijack the connections through an HTTP proxy. Google up a good way to do this if you can't just set HTTP_PROXY on the client, or set up your filter running with the IP and port number of the current server, moving the real server to another IP.
So the actual TCP connections are between the client and you, then from you to the server. Then you don't have to deal with ACKs, because TCP always sees mission accomplished.
edit: I see the comments on the original already came up with this idea using iptables to redirect the traffic through your transparent proxy process on the same machine.
Well I've done what I suggested in my comment, and it works, even if it did feel a long-winded way of doing it.
The (or a) problem is that the web server now, understandably, thinks that every request comes from localhost. Really I would like this delay to be transparent to both client and server (except in time of course!). Is there anything I can do about this?
If not, what are the implications? Each HTTP session happens through a different port - is that enough for them to be separated completely as they should be? Presumably so considering it works when behind a NAT where the address for many sessions is the same.

Resources