DNS problem with own coded dns server

[#1]

Howdy,

I have a DNS server that I'm working on. It works despite all the complex packet stuff however it's not working properly.. which is kinda odd.

I say it works.. it returns the same results that querying another dns server returns.. but it's doing something quirky because when a browser performs a lookup it then doesn't connect and the nslookup command is somehow bringing back different results.

If I try using IE to reach www.ebay.co.uk then this happens:

Looking at two different cmd windows:

As you can see the end results from both of those are completely different - so I'm clearly missing something.

I'm tempted to think that I'm not linking the records together using pointers or something however as I understand it thats down to compression not a "must be" thing.

Wireshark isn't showing anything obvious either. All the parts of the header are the same (other than the ID) and so are the resource records that are returned. I'm stumped.

Any ideas please?

[#2]

Does it use DNSSEC

[#3]

I run my own BIND server and in my LAN configuration I set the address of the DNS server up via a subnet section in my dhcpd.conf file. However, you may need to (as I did) tell your router that the LAN has its own DNS server and you want to use that, and not the ISP provided ones.

I know I don’t need to say this but it makes me feel better knowing I have. DNS can be exploited remotely, if it is not configured correctly, and can also leak information about your network to the Internet.

[#4]

---

@Anonymous wrote:

However, you may need to (as I did) tell your router that the LAN has its own DNS server and you want to use that, and not the ISP provided ones.

I know I don’t need to say this but it makes me feel better knowing I have. DNS can be exploited remotely, if it is not configured correctly, and can also leak information about your network to the Internet.

---

My DNS server is currently using the router for its recursive lookups lol so i don't intend to change that setting on the router as the router is one of the tools in my debugging at the moment - along with googles 8.8.4.4 nameserver.

I'm aware that DNS can be exploited, I've not looked into that much at present as this server (for the time being) is purely for the lan so that i can reach machines easily via <machinename>.lan without having to edit the hosts file on each machine. Any other requests are looked up externally and returned to the client.

With that said, something did occur to me last night about a feature i've not yet even bothered introducing and i suddenly realised the browser might be using it - TCP connections. At present the server is using UDP but I'd not bothered implementing TCP yet as i just wanted to get it processing the records and packets of data correctly. I shall get TCP working over the next few days.

[#5]

Be very careful using nslookup to troubleshoot what could be low-level DNS issues as it can be very temperamental in its interpretation of results, particularly when chained CNAMEs are in play, and in a bid to be 'helpful' might well be masking over the true source of the problem. I would instead recommend dig (it can be obtained from the BIND software suite).

The automatic .net suffix showing in your browser suggests it is not content with the response received to its query. You say wireshark traces don't reveal anything but what does the packet with the DNS response contain? Is it an IP address? If the CNAME is long you might be tripping the 512-byte limit of UDP and thus the response is being truncated.

[#6]

In this case I'll take the advice of nslookup as it managed to return the correct cname record that i'd expect. If you look at the other window which was using my server it said the cname was the same as the domain queried!

The packet with the DNS reponse has 3 records. 2 are cnames and the 3rd is an IP address.

[#7 · Accepted solution]

Well I fixed it... something rather daft and idiotic which I had deliberately not bothered with.. this from the tcpipguide:

And there was me just marking the entire length at the beginning of the string and not breaking it up into segments with byte length markers.

Anyway it's now working (infact its how i navigated here this evening) so thanks for your input guys!

[#8]

We didn't have a chance in hell of solving that one.

[#9]

I know... but it's always useful to ask isn't it just in case someone points you in the right direction!

It was actually your remark about the browser not being content (which was the same as I was thinking) which made me take another look at the tcpipguide to see if I was missing anything - and I was!

In the code sample I found online the original author was simply putting a length byte at the beginning of the string and then sending it out in the reply packet - which as you can see from my dns resolver app, shows up as being valid.. but obviously the browsers are expecting several segments with their own length markers - along with the length marker for the RDATA.

Anyway.. it's fixed now so thank you everyone for your input.