Hey,

It would be nice to know what request it's actually making.

To find that you'd need to turn on Debug Logging. You can do that by opening the DNS Console, head to Properties for the Server, then the Debug Logging tab.

That will allow us to capture the request it's actually making.

Chris

Ok, will do. Also, I've noticed in advanced TCP/IP properties for the dns server 192.168.1.253 that 'Register the server in DNS' isnt ticked. Should I tick this?

You would normally have that ticked, yes. Are there any other network interfaces on that server?

Chris

Theres 1 other NIC but it is disabled.

I turned on the logging and a few events have just occured. They're only the same however as is in the event log:

DNS Server log file creation at 18/02/2008 11:10:42 UTC
Log file wrap at 19/02/2008 11:24:32

Message logging key (for packets - other items use a subset of these fields):
      Field #  Information         Values
      -------  -----------         ------
         1     Date (in yyyymmdd format)
         2     Time (in 24-hour hh:mm:ss format)
         3     Thread ID
         4     Context
         5     UDP/TCP indicator
         6     Send/Receive indicator
         7     Remote IP
         8     Xid (hex)
         9     Query/Response      R = Response
                                   blank = Query
        10     Opcode              Q = Standard Query
                                   N = Notify
                                   U = Update
                                   ? = Unknown
        11     [ Flags (hex)
        12     Flags (char codes)  A = Authoritative Answer
                                   T = Truncated Response
                                   D = Recursion Desired
                                   R = Recursion Available
        13     ResponseCode ]
        14     Question Name

20080219 11:34:57 FE0 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.
The event data contains the DNS packet.
20080219 11:34:57 FE0 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.
20080219 11:34:57 FE0 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.
The event data contains the DNS packet.
20080219 11:34:57 FE0 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.
20080219 11:35:01 FE0 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.
The event data contains the DNS packet.
20080219 11:35:01 FE0 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.
20080219 11:35:05 FE0 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.
The event data contains the DNS packet.
20080219 11:35:05 FE0 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.

All those event occur after the Log File Wrap. You might try setting a larger size for the log file. Did you tick all the boxes under Debug Logging? And did you set a Filter at all?

Chris

The file size is set to 500000000 bytes. All boxes are ticked apart from details and I have set a filter yes with the IP addresses of the 2 DNS servers.

Is this right?

Yep, that sounds good to me.

Chris

Debug log is now 17kb with more of the same events being repeated.

Still nothing in the file at all?

Chris

Sorry I'm not sure what you mean Chris? That post of mine beginning 'Theres 1 other NIC but it is disabled', all the stuff after that is from the debug file...Just loads of these...

20080219 11:35:01 FE0 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.
20080219 11:35:05 FE0 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.

In the log file it's creating as part of Debug Logging, does it only have the header section?

Chris

What I posted above is from the log file thats created by the debugging.

I know, we've got the event (which it will log regardless of the filter), but we need the packet (which we're not getting at the moment).

You may need to take the filters off.

Does 1.2 have 1.253 set as Forwarder (Properties for the Server, Forwarders)?

Chris

Turned off filter but the log is just now going to radidly fill with loads of dns requests as 253 is also running proxy software.

Forwarders are setup as follows:
- 192.168.1.253 has forwarders setup to external dns servers.
- 192.168.1.2 doesnt have forwarders setup.

To a certain extent those kind of (bad) requests are unavoidable, however, normally you'd expect them to originate externally.

The only alternative is to use a Packet Sniffer to attempt to capture the DNS request, that won't really be any easier than working with Debug Logging, just gives you more configurable filters.

Chris

Ya I've noticed them before from external sources and just ignored them basically. However internally is a new one and the error about a domain name exceeding maximum length from my own dns server is unusual. Would a packet sniffer tell me more? Any recommendations?

It would tell you everything, but everything might be rather too much. You'd have to begin by filtering out all the regular network traffic. Ultimately you'll be digging through the DNS Requests one at a time until you find the correct filter.

By the time you've finished you may find it better to trawl through the DNS log file, aiming for a time-stamp match.

Far from ideal situation, but the data returned in the standard Event ID is rubbish (as you've seen).

Chris

Ok, I havent had one of the bad packets since 12:17 so I'll keep an eye and look for a time stamp match when it reoccurs...

Probably not that interesting but 2003 DNS breaks the original RFC for DNS and can advertise and accept larger than 512 byte DNS packets.  2000 doesn't understand them

http://articles.techrepublic.com.com/5100-6345_11-5091116.html 

It is interesting, but it should only be sending out packets greater than 512b (Extended) if the server performing the query advertises support for EDNS.

Only Windows 2003 and above can do that on the MS side, so we should be safe from such a thing on the 2000 server.

That doesn't necessarily mean something isn't sending extended packets at the server without receiving the advertisement.

Chris

Just checked the debug log again and a few more of the same events logged at 9:36 this morning:
------------------------------------------------------------------------------------------
20080220 09:37:08 FE0 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.
The event data contains the DNS packet.
20080220 09:37:08 FE0 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.
20080220 09:37:12 FE4 EVENT   The DNS server encountered a domain name exceeding the maximum length in the
packet from 192.168.1.253.
The event data contains the DNS packet.
20080220 09:37:12 FE4 EVENT   The DNS server encountered an invalid domain name in a packet from 192.168.1.253.
The packet will be rejected.
The event data contains the DNS packet.
----------------------------------------------------------------------------------------------

Im going to increase the points to 500 as I'm stumped and would be delighted to know why my own dns server is behaving like this...

Still no packet logged in the text file though?

It's one of those annoying things, can't do anything at all unless it's possible to identify the failing packet :-\

It states "The event data contains the DNS packet." does it actually have anything else in the Event Log at all?

Chris

Theres nothing else in the event log no, no packet info :(

Heres some extra info just in case anything is relevant (cluthing at straws basically).

The Win2003 192.168.1.253 server is also a file server and a proxy server running Symantec Web Security 3.0

On the Win2k 192.168.1.2 server something strange i've just noticed. i used to be able to map to various shares on the server just using its name. Now I notice I have to use the FQDN from my workstation to map to a share?

Also, my domain is only win 2k and XP machines with static IPs on the clients aswell as servers. Should  allow only secure dns updates be enabled on both DNS servers yes?

Ok, I'll try the sniffer approach and see what it shows up..

Okay, yell if you need any help with it. You'll get a hell of a lot logged. Initially I recommend you filter with:

udp dst port 53 or udp src port 53

It should be noted that the Capture Filter syntax is completely different from the Filter syntax on the main dump.

Chris

What is your replication set to in DNS?  All servers in forest / domain / etc?

Replication will not effect Queries as the mechanism used isn't at all the same. AD Replication as opposed to DNS traffic. In essence, Replication problems will not create the errors seen above.

For 2000 it will be all DCs in the AD Domain or Standard Primary, it was only split out into DNS Servers in the Forest / Domain with 2003.

Chris

Just FYI Chris no occurances of issue yet since filter started, Keeping an eye on it...

Ok, I've had the same events logged in event viewer again and have the wireshark log however I'm not sure what exactly I should be looking for in it?

Okay, you set the Capture Filter mentioned before? If so, we should only have DNS traffic to look at.

Next, we can see if we can see the request from a specific server. Apply this filter (in the main capture view):

ip.addr eq 192.168.1.253

That should reduce the capture to only include traffic to and from the server we're seeing in the error message.

Once done, it's a bit of a case of looking through, start by selecting a packet.

You can see the Time for each packet by expanding "Frame", the Arrival Time there will help. And you can see the contents of the query (or response) by expanding the "Domain Name System" section.

Chris

Sorry for delay Chris, snowed under here with 100 other things. Looking at the packets in the timeframe of the events being logged there are many packets.

They are all of "Standard Query Response" and all apart from one with a source of the external DNS server setup on the problem servers (.253) forwarders tab. The destination is 192.168.1.253 on all as per filter.

i dont understand all thats in the packet info but I cant see anything that looks like it is my 2 servers talking and one sending bad packet data to the other?

You've looked through each of the responses?

It's very unfortunate that you have so much other traffic between the server in question and 192.168.1.253, it'll make it very difficult to isolate simple because there's so much to check.

Chris

@chris
You are of course correct, I was just wondering if it was possible it was set to the forest and as this is a 2003 scope then it was sending out eDNS packets instead thinking the recipient was compatible?  Just a random idea, not sure if it was possible.

Always worth considering, I wouldn't completely discount it, whether unlikely or not :)

Chris

Replication set to all Domain Controllers in AD domain guys.

I've been through the log thourghly and I dont see anything unusual, im at a loss as to what to do at this stage. Given the Symantec Proxy software on the server I might disable that service come Friday evening as users wont need webaccess over the weekend, see does that have any affect on things.

Other than that aside from another reboot its all I can think of at the moment.

Well that's no fun, it goes around in circles really. Unless you can capture the packet and see exactly what it's upset about there's nothing at all you can do to stop it happening :-\

Chris

ya, im curious as to why it only seems to happen in the morning/afternoon time. Its only at this time web traffic is going through the server and also the Symantec software was recently upgraded though i cant see why it would have any affect on dns.
unfortunately I cant see anything strange in the packet filter though maybe I'm missing something. At least with the symantec service disabled over the weekend there'll be no web traffic going though dns server and if error still reoccurs I can rule that out?

Yep, it's not a bad plan.

Chris

I'll try it and see what happens, thanks for all your help so far Chris, I'll post back Monday with latest...

Okay, have a good weekend :)

Chris

Just checked in here to see what had happened after disabling the symantec web security service and there are no more of the events logged since. Interesting, Havent time now but might reinstall it tomorrow if I can...

Update, I left the web security service disabled all weekend and not one of those dns events was logged. I didnt get time sunday to reinstall it but will get to it at some stage during the week, its a file server aswell as proxy so I cant just reboot it when I want. Why would proxy software possible be causing events like this anyone?! I've inherited this rather quirky symantec software and its only the latest in a list of issues with it.

Without fully knowing the software and without seeing the packet you'd have to assume that the Symantec software was mangling a DNS request it was making on behalf of a client.

Chris

Hi Chris,

Having tested some mroe to be 100% this error is definitely linked to the web security software. Its been reinstalled and reconfugured and still the events occur. I've been planning on changing it for a while anyway to something more robust and usable so I've got the go ahead to get Surf Control. These events coincided with a version upgrade of the sws too which says alot. I'm awarding you the points anyway...cheers for all the help

Good luck, I hope Surfcontrol behaves itself a little better.

Chris