Event ID: 5504

  • Thread starter Thread starter Natalie Polanco
  • Start date Start date
N

Natalie Polanco

I've googled and looked up the kb articles on this warning in my event log.
I don't have forwarding setup on my DNS Servers. I have an AD domain with
both Windows 2000 DC's running DNS. One server has no messages, the other is
full of them. They all reference root servers ip addresses. I've seen many
posts about this but no solutions other than making sure forwarding is not
on. Any suggestions? Below is the event log message.

Event ID: 5504
Source: DNS
Time: 13:03
Category: None
Type: Warning
Description: The DNS server encountered an invalid domain name in a packet
from 192.5.5.241. The packet is rejected.

Any help would greatly by appreciated.

Thanks.
Natalie
 
In
Natalie Polanco said:
I've googled and looked up the kb articles on this warning in my
event log. I don't have forwarding setup on my DNS Servers. I have an
AD domain with both Windows 2000 DC's running DNS. One server has no
messages, the other is full of them. They all reference root servers
ip addresses. I've seen many posts about this but no solutions other
than making sure forwarding is not on. Any suggestions? Below is the
event log message.

Event ID: 5504
Source: DNS
Time: 13:03
Category: None
Type: Warning
Description: The DNS server encountered an invalid domain name in a
packet from 192.5.5.241. The packet is rejected.

Any help would greatly by appreciated.

You will need to set up a packet sniffer first to see what is being sent to
the root servers that is getting rejected.
5504 can be caused by Win9x computers with an illegal character in their
name or even just a conjested link. You could also need a hotfix for the
server.
http://www.eventid.net/display.asp?eventid=5504&eventno=642&source=DNS&phase=1
 
In
You will need to set up a packet sniffer first to see what is being
sent to the root servers that is getting rejected.
5504 can be caused by Win9x computers with an illegal character in
their
name or even just a conjested link. You could also need a hotfix for
the server.
http://www.eventid.net/display.asp?eventid=5504&eventno=642&source=DNS&phase=1


See if this helps as well;

838969 - Event 5504 & 7063 is recorded in the DNS log of Event Viewer in
Windows 2000 Server:
http://support.microsoft.com/?id=838969

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit. This posting is provided "AS-IS" with no warranties and
confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
In
InBan said:
I posted a similar question here:

http://communities2.microsoft.com/c...exp=&mid=7918078e-64c2-4284-9966-856346c5e218

I found that sniffing packets at my gateway to determine the request
being sent to the root hints by our internal DNS servers revealed
that the query being sent to the internet was a resolution request
for the hostname LOCALHOST. DNS servers should never attempt to
resolve this host name externally. It should always be resolved by
the internal host file on the server which contains a record mapping
localhost to 127.0.0.1 which is a loopback address.

The article you posted regarding the hotfix has an insufficient
amount of information about the issues cause. Is it to address this
issue? I do not have 7063 messages in my event log. All other
articles I have found regarding this message have been irrelevant to
the situation.

I have also found several posts on variouse forums looking for a
resolution to this issue, noone has been able to provide a solution
as of yet. This does adversely affect the server as the messages can
quickly fill your DNS event log, which under times of normal activity
is a relatively inactive log, and the DNS server is pre-occupied
performing resolution attempts of this illegal host name.

Part of what bothered me about this issue was the regularity of the
messages, they seem to be almost exactly 15 minutes apart for a
period of several days, then they subside for a month or more, then
return at the same frequency.

Any input would be greatly appreciated.

Ian Bagnald
Systems Administrator
Focal Technologies Corporation
Division of Kaydon Corporation
MCSE:Security Windows 2000
MCSA:Security Windows 2000
COMPTIA A+

This may sound like a rhetorical question but, is there a localhost entry in
your hosts file on all machines?
localhost shouldn't even go to the DNS server in the first place, it is
probably being sent to the DNS server by another machine with a corrupted
hosts file.

I did find a workaround, create a Forward Lookup zone named localhost and
put a blank (same as parent folder) record with IP 127.0.0.1.
I tested this, (see below) if I queried DNS for localhost it logged a 5504,
I created a localhost forward lookup zone and the blank host with IP
127.0.0.1 IP. Then I queried DNS for localhost, no events logged, and it
resolved to 127.0.0.1 by default DNS has a 127.in-addr.arpa. reverse lookup
zone.

Before.
localhost
Server: kjweb.lsaol.com
Address: 192.168.0.2

*** kjweb.lsaol.com can't find localhost: Non-existent domain
localhost
Server: kjweb.lsaol.com
Address: 192.168.0.2

Along with this DNS logged a 5504 event.

Event Type: Warning
Event Source: DNS
Event Category: None
Event ID: 5504
Date: 7/2/2004
Time: 03:36:54
User: N/A
Computer: KJWEB
Description:
The DNS server encountered an invalid domain name in a packet from
199.5.157.128. The packet is rejected.


After
localhost.
Server: kjweb.lsaol.com
Address: 192.168.0.2

Name: localhost
Address: 127.0.0.1

No event logged.
 
Has anyone actually tried the hotfix that is referenced in kb838969? I
called Microsoft and got the hotfix but I am very hesitant to install it
since it hasn't been regression tested. Anyone have any results of
installing it?


InBan said:
I posted a similar question here:

http://communities2.microsoft.com/c...exp=&mid=7918078e-64c2-4284-9966-856346c5e218

I found that sniffing packets at my gateway to determine the request being
sent to the root hints by our internal DNS servers revealed that the query
being sent to the internet was a resolution request for the hostname
LOCALHOST. DNS servers should never attempt to resolve this host name
externally. It should always be resolved by the internal host file on the
server which contains a record mapping localhost to 127.0.0.1 which is a
loopback address.
The article you posted regarding the hotfix has an insufficient amount of
information about the issues cause. Is it to address this issue? I do not
have 7063 messages in my event log. All other articles I have found
regarding this message have been irrelevant to the situation.
I have also found several posts on variouse forums looking for a
resolution to this issue, noone has been able to provide a solution as of
yet. This does adversely affect the server as the messages can quickly fill
your DNS event log, which under times of normal activity is a relatively
inactive log, and the DNS server is pre-occupied performing resolution
attempts of this illegal host name.
Part of what bothered me about this issue was the regularity of the
messages, they seem to be almost exactly 15 minutes apart for a period of
several days, then they subside for a month or more, then return at the same
frequency.
 
In
Natalie Polanco in said:
Has anyone actually tried the hotfix that is referenced in kb838969? I
called Microsoft and got the hotfix but I am very hesitant to install
it
since it hasn't been regression tested. Anyone have any results of
installing it?

I haven't tried it yet, and just to point out and mention, one of my clients
had this popping up a couple of years ago. I researched it and found, as
Kevin said, that this is primarily caused by an illegal character in a host
name. Illegal character such as a space or underscore. I found two Mac
machines with those characters in their names, and guess what, I changed the
names and the error disappeared.3

Kevin asked if there are any names in your infrastructure with an illegal
character, but I'm not sure if I saw your response, unless my newsreader
didn't display all the responses.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroup so all
can benefit.
This posting is provided "AS-IS" with no warranties and confers no
rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken; A lifetime commitment for a
pig. --
=================================
 
The only character I have in some of the names is a dash like dana-laptop. I
bet this could definitely cause a problem. I will try changing those names
to see if it made a difference. I also tried the suggestion about of
creating a forward lookup zone for localhost. I did that at 9:36am this
morning and as of now 11:28, the messages stopped as soon as I made the
change. I will be keeping a close eye out.

Thank you so much for all your answers - ALL of you - it is very much
appreciated.
"Ace Fekay [MVP]"
 
In
Natalie Polanco in said:
The only character I have in some of the names is a dash like
dana-laptop. I bet this could definitely cause a problem. I will try
changing those names to see if it made a difference. I also tried the
suggestion about of creating a forward lookup zone for localhost. I
did that at 9:36am this morning and as of now 11:28, the messages
stopped as soon as I made the change. I will be keeping a close eye
out.

Thank you so much for all your answers - ALL of you - it is very much
appreciated.

No problem Natalie.

A dash should be fine. Keep with the localhost forward lookup zone if that
fixes it. Post back with any concerns!

Ace
 
I did examin the hosts files on the DNS servers, they did contain the localhost record. I also examined the network traffic to and from the DNS servers at the time. No clients had made a localhost resolution request to the internal DNS servers. If they had the DNS server should NOT have forwarded it to the root hint.

I did consider puting a record in forward lookup for localhost before posting. However it would not explain WHY the DNS servers are making repeated requests to the public DNS servers to resolve localhost. I may try this workaround as the 5504 records are flooding the logs.

An illegal character should not cause this type of behaviour. The reason illegal characters in host names are associated with 5504 warnings is because they cannot be corrctly resolved by DNS. The repsonses from the Root Hint servers are those that are being dropped; they are considered to contain illegal characters because they are not the response that the DNS server is expecting. If LOCALHOST requests were illegal internal requests the ip address referenced in the warning would be internal, not that of the root hint. Note that localhost is not an illegal request, it should however always be resolved without being passed to a name server. Also if this was casued by an illegal charcter of an internal host, the ip address would be internal, not a public root hint.

Ian Bagnald
Systems Administrator
Focal Technologies Corporation
Division of Kaydon Corporation
MCSE:Security Windows 2000
MCSA:Security Windows 2000
COMPTIA A+
 
In
InBan in said:
I did examin the hosts files on the DNS servers, they did contain the
localhost record. I also examined the network traffic to and from the
DNS servers at the time. No clients had made a localhost resolution
request to the internal DNS servers. If they had the DNS server
should NOT have forwarded it to the root hint.

I did consider puting a record in forward lookup for localhost before
posting. However it would not explain WHY the DNS servers are making
repeated requests to the public DNS servers to resolve localhost. I
may try this workaround as the 5504 records are flooding the logs.

An illegal character should not cause this type of behaviour. The
reason illegal characters in host names are associated with 5504
warnings is because they cannot be corrctly resolved by DNS. The
repsonses from the Root Hint servers are those that are being
dropped; they are considered to contain illegal characters because
they are not the response that the DNS server is expecting. If
LOCALHOST requests were illegal internal requests the ip address
referenced in the warning would be internal, not that of the root
hint. Note that localhost is not an illegal request, it should
however always be resolved without being passed to a name server.
Also if this was casued by an illegal charcter of an internal host,
the ip address would be internal, not a public root hint.

Ian Bagnald
Systems Administrator
Focal Technologies Corporation
Division of Kaydon Corporation
MCSE:Security Windows 2000
MCSA:Security Windows 2000
COMPTIA A+

Good point Ian. After re-reading the original post, I see its a Root. Now
knowing the impact of the hotfix, maybe the more cautious resolution would
be the localhost record in your zone.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
I'd still like to know why the DNS servers are trying to resolve localhost. It shouldn't be necessary to have a localhost entry in forward lookup. This query isn't being generated by a client, it is coming from the internal Windows DNS server. The frequency/regularity bothers me. For 3 or 4 days every 1 or two months, every 15 minutes it sends four queries to each root hint server to resolve localhost. This does not seem to be normal behaviour.

Ian Bagnald
Systems Administrator
Focal Technologies Corporation
Division of Kaydon Corporation
MCSE:Security Windows 2000
MCSA:Security Windows 2000
COMPTIA A+
 
In
InBan said:
I'd still like to know why the DNS servers are trying to
resolve localhost. It shouldn't be necessary to have a
localhost entry in forward lookup. This query isn't being
generated by a client, it is coming from the internal
Windows DNS server. The frequency/regularity bothers me.
For 3 or 4 days every 1 or two months, every 15 minutes
it sends four queries to each root hint server to resolve
localhost. This does not seem to be normal behaviour.

Possibly it is coming from its own client, I can't think of a reason why a
DNS server would try to resolve a name unless it is asked to resolve it.
What else is on the box?
Is the DNS client service running?
Does ipconfig /displaydns display localhost?
 
Kevin;

Localhost is listed first when ipconfig /displaydns is run. The DNS client service is also running on the server.

My organization is made up of about 20 locations; each has at least one internal DNS server. Each server that is receiving these messages has local access to the internet and is configured to use root hint servers. Until recently all locations were connected by frame relay. Now each location has an ISA server and persistent VPN connections serve as the inter-site back-bone. Prior to the VPN implementation only one server saw these messages regularly. At that time all other internal DNS servers were configured to forward requests to that server if they were unable to resolve the request. Now that the forwarders have been removed and the internal DNS servers at each site are using the root hint servers for resolution all DNS servers in the organization (which I have examined) are receiving these messages. Each of these DNS servers may or may not also run DHCP, WINS, Exchange, AD and other services.

Ian Bagnald
Systems Administrator
Focal Technologies Corporation
Division of Kaydon Corporation
MCSE:Security Windows 2000
MCSA:Security Windows 2000
COMPTIA A+
 
Not to get off track, but curious, and not sure if it relates, but is your
domain a single label name?

Ace


InBan said:
I'd still like to know why the DNS servers are trying to resolve
localhost. It shouldn't be necessary to have a localhost entry in forward
lookup. This query isn't being generated by a client, it is coming from the
internal Windows DNS server. The frequency/regularity bothers me. For 3 or 4
days every 1 or two months, every 15 minutes it sends four queries to each
root hint server to resolve localhost. This does not seem to be normal
behaviour.
 
Also, do you have Secure Cache against Pollution enabled?

Ace

InBan said:
I'd still like to know why the DNS servers are trying to resolve
localhost. It shouldn't be necessary to have a localhost entry in forward
lookup. This query isn't being generated by a client, it is coming from the
internal Windows DNS server. The frequency/regularity bothers me. For 3 or 4
days every 1 or two months, every 15 minutes it sends four queries to each
root hint server to resolve localhost. This does not seem to be normal
behaviour.
 
Sorry for the slow response. No it is not a single label domain, and yes secure against cache polution is enabled. Actually my first concern when I saw all those errors was cache poisoning, but I'm convinced that is not the case. If this is a configuration issue, its not an obviouse one, and if its an issue with the Windows DNS implementation, its not (well) published.

Ian Bagnald
Systems Administrator
Focal Technologies Corporation
Division of Kaydon Corporation
MCSE:Security Windows 2000
MCSA:Security Windows 2000
COMPTIA A+
 
In
InBan said:
Sorry for the slow response. No it is not a single label domain, and
yes secure against cache polution is enabled. Actually my first
concern when I saw all those errors was cache poisoning, but I'm
convinced that is not the case. If this is a configuration issue, its
not an obviouse one, and if its an issue with the Windows DNS
implementation, its not (well) published.

This is an elusive issue. I understand as well that if it were an illegal
character in a client, and the client were to register, then I believe it
would appear as if the DNS server itself is querying to the Root servers,
assuming (none of us have asked your config yet) that you have all your
machines using your DNS, but assuming you don't have a forwarder configured.
Please correct me if my assumption is incorrect. Not saying it would or
would not fix it, but do you have forwarding configured? IF you do, try
removing it, but from the looks, it seems that you may not?

As for the localhost resolution, that seems odd that it would try to query
the Roots for it. Do you by chance have 127.0.0.1 as your DNS address? I
guess it would be prudent if we can ask for some config info, such as an
ipconfig /all, is DNS mutlihomed, if so, is it performing NAT, and anything
else you can think of that may or may not be relevant at first glance.

Also, as Kevin mentioned earlier, a saturated link can cause this. If during
the time the errors popped up, can you recall if there is heavy Internet
traffic across your link, such as file transfers, or something else? Do you
have logging set or anyway to check bandwidth usage by time/date stamp? Most
ISPs offering T1s have some sort of administration page that show
statistics, etc. I remember one guy called me with a saturated link that
wound up being a server that gotted 'pubbed'. It got pubbed twice. Two
separate instances. I removed both and it cleaned it up, but he wasn't
getting 5504s since his forwarding scheme was to his main office and not
from that location. So maybe if in a situation where there's saturation or a
DNS server overloaded, it could retrieve a valid packet, but due to
corruption, DNS is translating it as something else and results in that
error. Just maybe that hotfix takes care of this, but as for regression
testing as Natalie asked previously, I don;t know anyone that has applied
it, nor has anyone posted any issues about it as of yet.

Hope we can come down to a resolution here. 5504's come up time to time, but
they wind up being an internal client name issue, but not from what you're
describing, and frankly, believe it or not, I thought about this off and on
all weekend.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Its good to know I'm not the only one this is nagging at. Some of the other guys in IT in my organization didn't seem very interested in trying to pin this one down, but there is just something about it that bothers me.

A note on my config; no forwarders to external servers are used, all clients use only internal DNS. Internal DNS servers are configured to use root hints. 127.0.0.1 is not used to specify a DNS server in the servers IP Config. Internal DNS servers are configured to use themselves, by their static assigned IP, and their peers.

Here is some real food for thought. Check out the details of this packet capture. The first packet is a query sent to a root hint server (source and destination are the ip of the internal DNS server and the gateway). The second packet is the response from the root hint. The response is from a different root hint than the query was sent to, there are just so many of these I just grabbed two, they are all essentially identical.

(note I doctored it a little because I don't like exposing my internal IP addresses to the world, though a determined individual could pull the info from the hex, it would be rather pointless.):

Frame 25976 (69 bytes on wire, 69 bytes captured)
Arrival Time: Jun 30, 2004 12:04:27.340885000
Time delta from previous packet: 0.000065000 seconds
Time since reference or first frame: 133.065232000 seconds
Frame Number: 25976
Packet Length: 69 bytes
Capture Length: 69 bytes
Ethernet II, Src: 00:0x:xx:xx:xx:xx, Dst: 00:x0:xx:x0:xx:xx
Destination: 00:x0:xx:x0:xx:xx (192.168.xx.xxx)
Source: 00:0x:xx:xx:xx:xx (192.168.xx.x)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.xx.x (192.168.xx.x), Dst Addr: 192.228.79.201 (192.228.79.201)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 55
Identification: 0xd92a (55594)
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x742f (correct)
Source: 192.168.xx.x (192.168.xx.x)
Destination: 192.228.79.201 (192.228.79.201)
User Datagram Protocol, Src Port: 1273 (1273), Dst Port: domain (53)
Source port: 1273 (1273)
Destination port: domain (53)
Length: 35
Checksum: 0x3382 (correct)
Domain Name System (query)
Transaction ID: 0x217b
Flags: 0x0000 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... .0.. .... = Z: reserved (0)
.... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
localhost: type A, class inet
Name: localhost
Type: Host address
Class: inet

0000 00 c0 9f 10 de 21 00 06 5b fd 9d 97 08 00 45 00 .....!..[.....E.
0010 00 37 d9 2a 00 00 80 11 74 2f c0 a8 1c 06 c0 e4 .7.*....t/......
0020 4f c9 04 f9 00 35 00 23 33 82 21 7b 00 00 00 01 O....5.#3.!{....
0030 00 00 00 00 00 00 09 6c 6f 63 61 6c 68 6f 73 74 .......localhost
0040 00 00 01 00 01 .....


____________________________________________________________________________


Frame 25984 (144 bytes on wire, 144 bytes captured)
Arrival Time: Jun 30, 2004 12:04:27.404963000
Time delta from previous packet: 0.021646000 seconds
Time since reference or first frame: 133.129310000 seconds
Frame Number: 25984
Packet Length: 144 bytes
Capture Length: 144 bytes
Ethernet II, Src: 00:x0:xx:x0:xx:xx, Dst: 00:0x:xx:xx:xx:xx
Destination: 00:0x:xx:xx:xx:xx (192.168.xx.x)
Source: 00:x0:xx:x0:xx:xx (192.168.xx.xxx)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.112.36.4 (192.112.36.4), Dst Addr: 192.168.xx.x (192.168.xx.x)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 130
Identification: 0x66c4 (26308)
Flags: 0x00
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x1284 (correct)
Source: 192.112.36.4 (192.112.36.4)
Destination: 192.168.xx.x (192.168.xx.x)
User Datagram Protocol, Src Port: domain (53), Dst Port: 1273 (1273)
Source port: domain (53)
Destination port: 1273 (1273)
Length: 110
Checksum: 0x5556 (correct)
Domain Name System (response)
Transaction ID: 0x217b
Flags: 0x8403 (Standard query response, No such name)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...0 .... .... = Recursion desired: Don't do query recursively
.... .... 0... .... = Recursion available: Server can't do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... .... 0011 = Reply code: No such name (3)
Questions: 1
Answer RRs: 0
Authority RRs: 1
Additional RRs: 0
Queries
localhost: type A, class inet
Name: localhost
Type: Host address
Class: inet
Authoritative nameservers
<Root>: type SOA, class inet, mname A.ROOT-SERVERS.NET
Name: <Root>
Type: Start of zone of authority
Class: inet
Time to live: 1 day
Data length: 64
Primary name server: A.ROOT-SERVERS.NET
Responsible authority's mailbox: NSTLD.VERISIGN-GRS.COM
Serial number: 2004062901
Refresh interval: 30 minutes
Retry interval: 15 minutes
Expiration limit: 7 days
Minimum TTL: 1 day

0000 00 06 5b fd 9d 97 00 c0 9f 10 de 21 08 00 45 00 ..[........!..E.
0010 00 82 66 c4 00 00 80 11 12 84 c0 70 24 04 c0 a8 ..f........p$...
0020 1c 06 00 35 04 f9 00 6e 55 56 21 7b 84 03 00 01 ...5...nUV!{....
0030 00 00 00 01 00 00 09 6c 6f 63 61 6c 68 6f 73 74 .......localhost
0040 00 00 01 00 01 00 00 06 00 01 00 01 51 80 00 40 ............Q..@
0050 01 41 0c 52 4f 4f 54 2d 53 45 52 56 45 52 53 03 .A.ROOT-SERVERS.
0060 4e 45 54 00 05 4e 53 54 4c 44 0c 56 45 52 49 53 NET..NSTLD.VERIS
0070 49 47 4e 2d 47 52 53 03 43 4f 4d 00 77 73 92 b5 IGN-GRS.COM.ws..
0080 00 00 07 08 00 00 03 84 00 09 3a 80 00 01 51 80 ..........:...Q.

The expiration, retry and refresh interval have to do with the frequency/regularity of the messages. But I don't know what is setting those values.

Ian Bagnald
MCSE:Security
MCSA:Security
COMPITA A+
 
In
InBan said:
Its good to know I'm not the only one this is nagging at. Some of the
other guys in IT in my organization didn't seem very interested in
trying to pin this one down, but there is just something about it
that bothers me.

A note on my config; no forwarders to external servers are used, all
clients use only internal DNS. Internal DNS servers are configured to
use root hints. 127.0.0.1 is not used to specify a DNS server in the
servers IP Config. Internal DNS servers are configured to use
themselves, by their static assigned IP, and their peers.

Here is some real food for thought. Check out the details of this
packet capture. The first packet is a query sent to a root hint
server (source and destination are the ip of the internal DNS server
and the gateway). The second packet is the response from the root
hint. The response is from a different root hint than the query was
sent to, there are just so many of these I just grabbed two, they are
all essentially identical.

(note I doctored it a little because I don't like exposing my
internal IP addresses to the world, though a determined individual
could pull the info from the hex, it would be rather pointless.):
<snip>


The expiration, retry and refresh interval usually is based on the zone
data, but that's strange.

That is also strange that 192.112.36.4 would respond to a query originally
sent to 192.228.79.201. Ian, do me a favor and set a forwarder and let me
know what happens. Usually in most cases we recommend forwarding for a
number of reasons, main one is to offload the recursion processing to
another server. I usually mention to use 4.2.2.2, or you can use whatever
you like that supports the RA bit.

--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory

HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
One didn't reply to a packet sent to the other, packets were sent to both, I just didn't grab the reply to that request but a reply to an identical request sent to one of the other root hints. The replies and queries are all identical other than the root hint servers ip. The response is the same.

The messages seem to have subsided for now, so if I did configure a forwarder at this point it wouldn't tell us if it fixed the issue. I'll wait and possibly try it the next time this happens, but if history is an indication, this wont happen again for about a month.

Thanks for the attention.
Ian
 
Back
Top