DNS fails to lookup www.microsoft.com and www.msn.com but works on ALL other sites...

I'm a bit embarrased to ask question re: software several years old but it's worked and there's been no compelling reason to upgrade PDS/BDS of our domain.  I don't know exactly when DNS lookups started failing, and it's with only with microsoft websites.  It's ironic that a microsoft software fails with lookup of its own websites.   I've gone thru all the FAQ's of expert-exchange and some suggest it's a PIX firewall issue with EDNS0, so I've already changed firewall's setting "fixup protocol dns maximum-length 4096" but alas the DNS still fails to lookup any microsoft websites.  Keep in mind this DNS works find with all other major sites, ie google.com, yahoo.com, ibm.com, cnn.com or whatever, BUT it fails with www.microsoft.com or www.msn.com or any microsoft website returning messages "DNS request timed out.    timeout was 2 seconds. *** ... can't find www.microsoft.com: Non-existent domain".  

 I even rebuilt fresh NT test system and still problem persists with lookup failure of microsoft websites, so I installed BIND9 on test system and it has no problem with lookup of microsoft websites.  So how to fix problem with original DNS.exe for Windows NT 4.0 server??

thank you in advance for your consideration,
LA0283Asked:
Who is Participating?
 
Computer101Commented:
PAQed with points refunded (250)

Computer101
EE Admin
0
 
2PiFLCommented:
I haven't worked with NT4 in "a while" but is "ipconfig /flushdns" supported by NT4?  Maybe you got some bad entries for MS.  
0
 
LA0283Author Commented:
I'm pretty sure this is not the problem, ie fresh install, reboot, etc result the same which is no lookup for any microsoft website.  Plus, this command is not support with Windows NT...
0
How do you know if your security is working?

Protecting your business doesn’t have to mean sifting through endless alerts and notifications. With WatchGuard Total Security Suite, you can feel confident that your business is secure, meaning you can get back to the things that have been sitting on your to-do list.

 
2PiFLCommented:

Suppose you config a workstation to use an external DNS server - maybe it's a poisoned dns server on the outside.  
0
 
Chris DentPowerShell DeveloperCommented:

The protocol fix only really applies to Windows 2003 DNS Servers, they need it so they can support Extended DNS Probes. Those are used, in part, to prevent cache poisoning.

Can the NT DNS Server resolve the Name Servers for microsoft.com? We can test that in nslookup:

C:\> nslookup
> set type=ns
> microsoft.com

Have you tried it with Forwarders configured at all?

Chris
0
 
LA0283Author Commented:
The result command per Chris-Dent...
C:\>nslookup
Default Server:  mssrv.coaster
Address:  192.168.5.78

> set type=ns
> microsoft.com
Server:  mssrv.coaster
Address:  192.168.5.78

Non-authoritative answer:
microsoft.com   nameserver = ns1.msft.net
microsoft.com   nameserver = ns2.msft.net
microsoft.com   nameserver = ns3.msft.net
microsoft.com   nameserver = ns4.msft.net
microsoft.com   nameserver = ns5.msft.net

ns1.msft.net    internet address = 207.68.160.190
ns2.msft.net    internet address = 65.54.240.126
ns3.msft.net    internet address = 213.199.161.77
ns4.msft.net    internet address = 207.46.66.126
ns5.msft.net    internet address = 65.55.238.126

Not sure what you mean "Have you tried it with Forwarders configured at all?"
simply ping from command prompt still cannot resolve domain despite above results...
C:\>ping microsoft.com
Bad IP address microsoft.com.

0
 
Keith AlabasterEnterprise ArchitectCommented:
try ping www.microsoft.com

I get a timeout personally rather than a bad address and this is because Microsoft have their firewalls set to not reply to ping requests.
0
 
LA0283Author Commented:
same result as domain...

C:\>ping www.microsoft.com
Bad IP address www.microsoft.com.
0
 
Keith AlabasterEnterprise ArchitectCommented:
Thats good - you get the same results that I get on my system both for the nslookup (which proves your DNS is working correctly on the server ate least) and from the ping  ie i cannot ping msoft either.

If you do the nslookup from a client, do you get the same nslookup results as when you did it from the server?

Can you post please an ipconfig /all from the server?

0
 
LA0283Author Commented:
results of...
C:\>ipconfig /all
Windows NT IP Configuration
        Host Name . . . . . . . . . : mssrv.coaster
        DNS Servers . . . . . . . . : 192.168.5.78
        Node Type . . . . . . . . . : Hybrid
        NetBIOS Scope ID. . . . . . :
        IP Routing Enabled. . . . . : No
        WINS Proxy Enabled. . . . . : No
        NetBIOS Resolution Uses DNS : No

Ethernet adapter IBMFE1:
        Description . . . . . . . . : IBM 10/100 EtherJet PCI Ada
        Physical Address. . . . . . : 00-06-29-13-07-1E
        DHCP Enabled. . . . . . . . : No
        IP Address. . . . . . . . . : 192.168.5.78
        Subnet Mask . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . : 192.168.5.1
        Primary WINS Server . . . . : 192.168.5.78
        Secondary WINS Server . . . : 192.168.5.78

PPP adapter NdisWan5:
        Description . . . . . . . . : NdisWan Adapter
        Physical Address. . . . . . : 00-00-00-00-00-00
        DHCP Enabled. . . . . . . . : No
        IP Address. . . . . . . . . : 0.0.0.0
        Subnet Mask . . . . . . . . : 0.0.0.0
        Default Gateway . . . . . . :

C:\>

However, using different domain google.com vs microsoft.com does produces positive results...
C:\>nslookup
Default Server:  mssrv.coaster
Address:  192.168.5.78

> set type=ns
> google.com
Server:  mssrv.coaster
Address:  192.168.5.78

Non-authoritative answer:
google.com      nameserver = ns1.google.com
google.com      nameserver = ns2.google.com
google.com      nameserver = ns3.google.com
google.com      nameserver = ns4.google.com

ns1.google.com  internet address = 216.239.32.10
ns2.google.com  internet address = 216.239.34.10
ns3.google.com  internet address = 216.239.36.10
ns4.google.com  internet address = 216.239.38.10
> exit

C:\>ping google.com

Pinging google.com [72.14.207.99] with 32 bytes of dat
Reply from 72.14.207.99: bytes=32 time=109ms TTL=245
Reply from 72.14.207.99: bytes=32 time=156ms TTL=245

C:\>
 
0
 
Chris DentPowerShell DeveloperCommented:

Does nslookup for www.microsoft.com return at all?

Chris
0
 
LA0283Author Commented:
From a client side the results of ping for both domains...

D:\>ping www.microsoft.com
Unknown host www.microsoft.com.

D:\>ping www.google.com

Pinging www.l.google.com [209.85.173.103] with 32 bytes of data:

Reply from 209.85.173.103: bytes=32 time=33ms TTL=247
Reply from 209.85.173.103: bytes=32 time=34ms TTL=247
Reply from 209.85.173.103: bytes=32 time=120ms TTL=247
Reply from 209.85.173.103: bytes=32 time=33ms TTL=247

Ping statistics for 209.85.173.103:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 33ms, Maximum =  120ms, Average =  55ms

D:\>
0
 
Keith AlabasterEnterprise ArchitectCommented:
That all looks as i would expect to see it. When accessing www.microsoft.com through a browser, are you getting the page or an error screen?
0
 
Chris DentPowerShell DeveloperCommented:

Such a shame the DNS servers don't return ICMP, that'd make life a lot easier right now.

Does your DNS Server use Forwarders? Did we already check that? :)

Chris
0
 
Chris DentPowerShell DeveloperCommented:

You should be getting back something like this:

www.microsoft.com
Server:  sol.highorbit.local
Address:  172.31.255.50:53

Non-authoritative answer:
Name:    lb1.www.ms.akadns.net
Addresses:  207.46.192.254, 207.46.193.254, 207.46.19.254, 207.46.19.190
Aliases:  www.microsoft.com, toggle.www.ms.akadns.net
          g.www.ms.akadns.net

When you run nslookup www.microsoft.com.

Chris
0
 
LA0283Author Commented:
on the server the nslookup results for both microsoft and google...
C:\>nslookup
Default Server:  mssrv.coaster
Address:  192.168.5.78

www.microsoft.com
Server:  mssrv.coaster
Address:  192.168.5.78

DNS request timed out.
    timeout was 2 seconds.
*** mssrv.coaster can't find www.microsoft.com: Non-existent domain
www.google.com
Server:  mssrv.coaster
Address:  192.168.5.78

Non-authoritative answer:
Name:    www.l.google.com
Addresses:  209.85.173.99, 209.85.173.147, 209.85.173.104, 209.85.173.103
Aliases:  www.google.com

>
0
 
Keith AlabasterEnterprise ArchitectCommented:
BTW - Happy New Year Chris, long time no speak. I think the DNS server MUST be using forwarders or root hints ok as the server is pointing to itself dor dns resolution and the nslookups are returning the right values from both clients and server.
0
 
Keith AlabasterEnterprise ArchitectCommented:
Something has changed here.
ID: 20675471            Author:LA0283         Date:01.16.2008 at 08:00PM GMT
This post above showed that you were getting the info correctly I thought?
0
 
Keith AlabasterEnterprise ArchitectCommented:
Can we have the ipconfig /all from the client as well then?
0
 
LA0283Author Commented:
client side of ipconfig /all...
D:\>ipconfig /all

Windows 2000 IP Configuration

        Host Name . . . . . . . . . . . . : icasrv3
        Primary DNS Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection 3:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Intel(R) 82566DC Gigabit Network Con
nection
        Physical Address. . . . . . . . . : 00-16-76-C1-D9-41
        DHCP Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.108.18
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . :
        DNS Servers . . . . . . . . . . . :

Ethernet adapter Local Area Connection 4:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : 3Com EtherLink XL 10/100 PCI For Com
plete PC Management NIC (3C905C-TX) #2
        Physical Address. . . . . . . . . : 00-04-75-95-96-FB
        DHCP Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.5.18
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.5.4
        DNS Servers . . . . . . . . . . . : 192.168.5.78
        Primary WINS Server . . . . . . . : 192.168.5.80
        Secondary WINS Server . . . . . . : 192.168.5.78

D:\>
0
 
Chris DentPowerShell DeveloperCommented:

And to you Keith, I hope you had a good one :)

I don't like that the DNS server isn't capable of returning IP Addresses for Names within the MS Domain. It would suggest that the DNS Servers for MS can't be contacted, however, they're so widely spread that the error, if there is one, must be close to the server.

The posting at 8 showed us retrieving the Name Server Records, almost certainly from the Parent server, but we can't seem to get past that.

Chris
0
 
Keith AlabasterEnterprise ArchitectCommented:
Hmmm - different default gateways and different wins server between server and client.... any reason?
0
 
LA0283Author Commented:
I can align the gateways and WINS servers but honestly I don't think it will make any difference.  All other domains and lookups seems to work fine on this DNS, with exception of microsoft.com and msn.com.   I'm unable to find any other domains that exhibit similar behavior...
0
 
Chris DentPowerShell DeveloperCommented:

Well nslookup executes the query against the DNS Server itself, so we should rule out client issues really (in my opinion).

Is the DNS Server configured to use Forwarders? Or are we going with Root Hints?

Chris
0
 
Keith AlabasterEnterprise ArchitectCommented:
No, I understand the frustration it must be causing. Have you cleared the cache on the dns server?
0
 
Chris DentPowerShell DeveloperCommented:

Missed an earlier comment. To find the Forwarders open up the DNS Console, right click on the server and select Properties. Forwarders exists as a tab there, if there aren't any configured it'll be using Root Hints and performing recursive name resolution.

Chris
0
 
LA0283Author Commented:
In "Forwarders" tab the "Use Forwarder(s)" is unchecked with no entries -- so it is using Root
0
 
Chris DentPowerShell DeveloperCommented:

Still have that BIND installation?

Can you try setting that server as the Forwarder on the MS Server and see if it still can't resolve MS?

Chris
0
 
LA0283Author Commented:
Do you mean running BIND and MS DNS at the same time on PDS?  wouldn't that create conflict with listening ports on PDS?
0
 
Chris DentPowerShell DeveloperCommented:

I didn't realise you were running them on the same server, so that's not such a good idea after all.

Does your ISP have DNS Servers we can forward to for a quick check?

Chris
0
 
LA0283Author Commented:
Yes, putting our ISP's DNS IP address in PDS's forwarder has ping resolving IP address for www.microsoft.com.  Also, the browser now resolves website www.microsoft.com, and client also can browse to www.microsoft.com 
0
 
Chris DentPowerShell DeveloperCommented:

Thought that might work...

That doesn't solve the problem, only works around it. For some reason it seems you're not able to contact the Name Servers for MS. Considering how widely dispersed they are that's quite surprising.

Lets try a few of them, Can you run these in nslookup:

> server 65.54.240.126
> set type=a
www.microsoft.com

That tells NSLookup to query one of Microsoft's Name Servers (ns2.msft.net in this case) and look for A records associated with our query.

Chris
0
 
LA0283Author Commented:
results of command...
C:\>nslookup
Default Server:  mssrv.coaster
Address:  192.168.5.78

> server 65.54.240.126
Default Server:  dns1.sj.msft.net
Address:  65.54.240.126

> set type=a
www.microsoft.com
Server:  dns1.sj.msft.net
Address:  65.54.240.126

*** No address (A) records available for www.microsoft.com
0
 
Keith AlabasterEnterprise ArchitectCommented:
Good call Chris
0
 
Chris DentPowerShell DeveloperCommented:

Not so sure about that, slow progress...

Sometimes I really don't like NSLookup. Would you mind downloading Dig please LA0283?

This is the version I use:

http://members.shaw.ca/nicholas.fong/dig/

Then we need to run a few more queries using that. So once you've unzipped it run:

dig www.microsoft.com

We're looking for it to come back with this set of nested Aliases:

www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

Then:

g.www.ms.akadns.net.    220     IN      CNAME   lb1.www.ms.akadns.net.

And finally this lot operating Round Robin:

lb1.www.ms.akadns.net.  220     IN      A       207.46.192.254
lb1.www.ms.akadns.net.  220     IN      A       207.46.193.254
lb1.www.ms.akadns.net.  220     IN      A       207.46.19.254
lb1.www.ms.akadns.net.  220     IN      A       207.46.19.190

I suspect you're not going to get the first CNAME, if that is the case I think we're going to need a Packet Sniffer on the server. Perhaps Wireshark (http://www.wireshark.org/).

Chris
0
 
LA0283Author Commented:
Chris: with forwarders still pointing to ISP's DNS the results are good and are the same as your last correspondences, so I presume you mean to run "dig" without forwarders enabled.  

So the result of dig without forwarders enabled:
C:\dig>dig www.microsoft.com

; <<>> DiG 9.3.2 <<>> www.microsoft.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

C:\dig>
0
 
Chris DentPowerShell DeveloperCommented:

I did, thanks for interpreting that :)

Normally only says that when there are no DNS servers configured on the system running the command. Still if it's misbehaving you can add DNS Servers into resolv.conf as in this example:

nameserver 123.234.123.234
nameserver 123.234.123.235

That should make Dig use those servers instead of the ones configured in your TCP/IP settings (which is hasn't seemed able to pick up).

Chris
0
 
LA0283Author Commented:
Chris: which instance of resolv.conf should I modify, ie c:\dig\resolv.conf or c:\winnt\system32\drivers\etc\resolv.conf for "dig" test??  

Already in my c:\winnt\system32\drivers\etc\resolv.conf contains entry:
nameserver 192.168.5.78

and, should it be removed for this test?
also, can file be modified with notepad -- seems extra binary cr lf sequence embedded within file, ie notepad displays black squares for no font translation??
hexdump of original resolv.conf file reveals:
0000000         6e616d65        73657276        65722031        39322e31
           n   a   m   e   s   e   r   v   e   r  sp   1   9   2   .   1
0000020         36382e35        2e37380d        0a0a0a0d        0a000000
           6   8   .   5   .   7   8  cr  lf  lf  lf  cr  lf            

0
 
Chris DentPowerShell DeveloperCommented:

C:\dig\resolve.conf, should be possible to edit it using Notepad, although Wordpad deals with the Carriage Return character rather better.

Chris
0
 
LA0283Author Commented:
with forwarders disabled the results are as follows:

C:\dig>dig www.microsoft.com

; <<>> DiG 9.3.2 <<>> www.microsoft.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

C:\dig>type resolv.conf
nameserver 123.234.123.234
nameserver 123.234.123.235




C:\dig>
0
 
Chris DentPowerShell DeveloperCommented:

Get the impression this whole thing just isn't interested in allowing itself to be solved??

Can you remove all entries from both versions of Resolv.conf? That should have it use the DNS Servers you get via DHCP, I hope.

Chris
0
 
LA0283Author Commented:
not sure what you mean by DHCP, ie using static entries on server...
result of dig command with forwarders disable and resolv.conf files removed...
C:\dig>dig www.microsoft.com

; <<>> DiG 9.3.2 <<>> www.microsoft.com
;; global options:  printcmd
;; connection timed out; no servers could be reached

And, yet www.yahoo.com and www.google.com continue to resolve okay even with forwarders disabled...
C:\dig>dig www.yahoo.com

; <<>> DiG 9.3.2 <<>> www.yahoo.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 572
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yahoo.com.                 IN      A

;; ANSWER SECTION:
www.yahoo.com.          156     IN      CNAME   www.yahoo-ht3.akadns.net.
www.yahoo-ht3.akadns.net. 0     IN      A       209.131.36.158

;; Query time: 265 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 18 13:26:38 2008
;; MSG SIZE  rcvd: 85


C:\dig>dig www.google.com

; <<>> DiG 9.3.2 <<>> www.google.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1845
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.google.com.                        IN      A

;; ANSWER SECTION:
www.google.com.         86239   IN      CNAME   www.l.google.com.
www.l.google.com.       139     IN      A       209.85.173.147
www.l.google.com.       139     IN      A       209.85.173.103
www.l.google.com.       139     IN      A       209.85.173.104
www.l.google.com.       139     IN      A       209.85.173.99

;; Query time: 62 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 18 13:26:50 2008
;; MSG SIZE  rcvd: 116


C:\dig>
0
 
LA0283Author Commented:
fyi, when forwarders enabled to ISP DNS of course dig www.microsoft.com works but I noticed the "MSG SIZE rcvd: 489" is significantly larger than results of www.yahoo.com and www.google.com -- maybe it's a buffer problem within NT 4.0 DNS??

C:\dig>dig www.microsoft.com
; <<>> DiG 9.3.2 <<>> www.microsoft.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1569
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 9, ADDITIONAL: 9

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      2963    IN      CNAME   toggle.www.ms.akadns.net.
toggle.www.ms.akadns.net. 270   IN      CNAME   g.www.ms.akadns.net.
g.www.ms.akadns.net.    270     IN      CNAME   lb1.www.ms.akadns.net.
lb1.www.ms.akadns.net.  83      IN      A       207.46.19.254
lb1.www.ms.akadns.net.  83      IN      A       207.46.192.254
lb1.www.ms.akadns.net.  83      IN      A       207.46.193.254
lb1.www.ms.akadns.net.  83      IN      A       207.46.19.190

;; AUTHORITY SECTION:
akadns.net.             14078   IN      NS      zb.akadns.org.
akadns.net.             14078   IN      NS      zc.akadns.org.
akadns.net.             14078   IN      NS      zd.akadns.org.
akadns.net.             14078   IN      NS      eur1.akadns.net.
akadns.net.             14078   IN      NS      use3.akadns.net.
akadns.net.             14078   IN      NS      use4.akadns.net.
akadns.net.             14078   IN      NS      usw2.akadns.net.
akadns.net.             14078   IN      NS      asia9.akadns.net.
akadns.net.             14078   IN      NS      za.akadns.org.

;; ADDITIONAL SECTION:
za.akadns.org.          99800   IN      A       195.219.3.169
zb.akadns.org.          100117  IN      A       206.132.100.105
zc.akadns.org.          100125  IN      A       124.211.40.4
zd.akadns.org.          99807   IN      A       63.209.3.132
eur1.akadns.net.        26914   IN      A       213.254.204.197
use3.akadns.net.        26919   IN      A       204.2.178.133
use4.akadns.net.        120439  IN      A       208.44.108.137
usw2.akadns.net.        44369   IN      A       63.209.3.132
asia9.akadns.net.       5484    IN      A       220.73.220.4

;; Query time: 312 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 18 13:30:39 2008
;; MSG SIZE  rcvd: 489
0
 
Chris DentPowerShell DeveloperCommented:

This time could you do:

dig @ISPsDNSServer www.microsoft.com

That one should work from what you've got back above so far.

Then can we do this, one command for each of Microsoft's DNS Servers:

dig @207.68.160.190 www.microsoft.com
dig @65.54.240.126 www.microsoft.com
dig @213.199.161.77 www.microsoft.com
dig @207.46.66.126 www.microsoft.com
dig @65.55.238.126 www.microsoft.com

Each one should (but probably won't) return:

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

Chris
0
 
LA0283Author Commented:
scratch my previous response it's not related to "MSG SIZE rcvd..." as www.msn.com returns only 80, but also doesn't work without forwarders enabled...

results from command:
C:\dig>dig @ISPsDNSServer www.microsoft.com
dig: couldn't get address for 'ISPsDNSServer': not found
0
 
Chris DentPowerShell DeveloperCommented:

Sorry, ISPsDNSServer should have been replaced with the IP you're using as the Forwarder at the moment.

e.g. @123.234.123.234

Chris
0
 
LA0283Author Commented:
results with forwarders disabled...

C:\dig>dig @66.51.205.100 www.microsoft.com

; <<>> DiG 9.3.2 <<>> @66.51.205.100 www.microsoft.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 493
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 9, ADDITIONAL: 9

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      1679    IN      CNAME   toggle.www.ms.akadns.net.
toggle.www.ms.akadns.net. 67    IN      CNAME   g.www.ms.akadns.net.
g.www.ms.akadns.net.    67      IN      CNAME   lb1.www.ms.akadns.net.
lb1.www.ms.akadns.net.  103     IN      A       207.46.192.254
lb1.www.ms.akadns.net.  103     IN      A       207.46.193.254
lb1.www.ms.akadns.net.  103     IN      A       207.46.19.190
lb1.www.ms.akadns.net.  103     IN      A       207.46.19.254

;; AUTHORITY SECTION:
akadns.net.             62268   IN      NS      zd.akadns.org.
akadns.net.             62268   IN      NS      eur1.akadns.net.
akadns.net.             62268   IN      NS      use3.akadns.net.
akadns.net.             62268   IN      NS      use4.akadns.net.
akadns.net.             62268   IN      NS      usw2.akadns.net.
akadns.net.             62268   IN      NS      asia9.akadns.net.
akadns.net.             62268   IN      NS      za.akadns.org.
akadns.net.             62268   IN      NS      zb.akadns.org.
akadns.net.             62268   IN      NS      zc.akadns.org.

;; ADDITIONAL SECTION:
za.akadns.org.          98496   IN      A       195.219.3.169
zb.akadns.org.          98498   IN      A       206.132.100.105
zc.akadns.org.          98506   IN      A       124.211.40.4
zd.akadns.org.          98508   IN      A       63.209.3.132
eur1.akadns.net.        19423   IN      A       213.254.204.197
use3.akadns.net.        119207  IN      A       204.2.178.133
use4.akadns.net.        17710   IN      A       208.44.108.137
usw2.akadns.net.        19646   IN      A       63.209.3.132
asia9.akadns.net.       130963  IN      A       220.73.220.4

;; Query time: 265 msec
;; SERVER: 66.51.205.100#53(66.51.205.100)
;; WHEN: Fri Jan 18 13:52:51 2008
;; MSG SIZE  rcvd: 489

0
 
Chris DentPowerShell DeveloperCommented:

Presumably all of the others fail?

dig @207.68.160.190 www.microsoft.com
dig @65.54.240.126 www.microsoft.com
dig @213.199.161.77 www.microsoft.com
dig @207.46.66.126 www.microsoft.com
dig @65.55.238.126 www.microsoft.com
0
 
LA0283Author Commented:
no, they do not fail...

C:\dig>dig @207.68.160.190 www.microsoft.com

; <<>> DiG 9.3.2 <<>> @207.68.160.190 www.microsoft.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1172
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

;; Query time: 78 msec
;; SERVER: 207.68.160.190#53(207.68.160.190)
;; WHEN: Fri Jan 18 14:05:09 2008
;; MSG SIZE  rcvd: 73


C:\dig>dig @65.54.240.126 www.microsoft.com

; <<>> DiG 9.3.2 <<>> @65.54.240.126 www.microsoft.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 592
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

;; Query time: 62 msec
;; SERVER: 65.54.240.126#53(65.54.240.126)
;; WHEN: Fri Jan 18 14:05:26 2008
;; MSG SIZE  rcvd: 73


C:\dig>dig @213.199.161.77 www.microsoft.com

; <<>> DiG 9.3.2 <<>> @213.199.161.77 www.microsoft.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1993
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

;; Query time: 234 msec
;; SERVER: 213.199.161.77#53(213.199.161.77)
;; WHEN: Fri Jan 18 14:05:40 2008
;; MSG SIZE  rcvd: 73


C:\dig>dig @207.46.66.126 www.microsoft.com

; <<>> DiG 9.3.2 <<>> @207.46.66.126 www.microsoft.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1181
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

;; Query time: 171 msec
;; SERVER: 207.46.66.126#53(207.46.66.126)
;; WHEN: Fri Jan 18 14:05:55 2008
;; MSG SIZE  rcvd: 73


C:\dig>dig @65.55.238.126 www.microsoft.com

; <<>> DiG 9.3.2 <<>> @65.55.238.126 www.microsoft.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1311
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com.             IN      A

;; ANSWER SECTION:
www.microsoft.com.      3600    IN      CNAME   toggle.www.ms.akadns.net.

;; Query time: 125 msec
;; SERVER: 65.55.238.126#53(65.55.238.126)
;; WHEN: Fri Jan 18 14:06:08 2008
;; MSG SIZE  rcvd: 73
0
 
Chris DentPowerShell DeveloperCommented:

That's with the Forwarder set?

Chris
0
 
LA0283Author Commented:
no forwarders set with last response...
0
 
Chris DentPowerShell DeveloperCommented:

That's rather interesting.

Can you try:

dig toggle.www.ms.akadns.net

Chris
0
 
LA0283Author Commented:
that works too, and re-affirm that www.microsoft.com still not resolving...

C:\dig>dig toggle.www.ms.akadns.net

; <<>> DiG 9.3.2 <<>> toggle.www.ms.akadns.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 233
;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;toggle.www.ms.akadns.net.      IN      A

;; ANSWER SECTION:
toggle.www.ms.akadns.net. 300   IN      CNAME   g.www.ms.akadns.net.
g.www.ms.akadns.net.    300     IN      CNAME   lb1.www.ms.akadns.net.
lb1.www.ms.akadns.net.  300     IN      A       207.46.19.190
lb1.www.ms.akadns.net.  300     IN      A       207.46.19.254
lb1.www.ms.akadns.net.  300     IN      A       207.46.192.254
lb1.www.ms.akadns.net.  300     IN      A       207.46.193.254

;; Query time: 265 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 18 14:13:19 2008
;; MSG SIZE  rcvd: 140


C:\dig>dig www.microsoft.com

; <<>> DiG 9.3.2 <<>> www.microsoft.com
;; global options:  printcmd
;; connection timed out; no servers could be reached
0
 
Chris DentPowerShell DeveloperCommented:

Forgot to submit my comment the other day.

I suppose it's still possible that the Firewall is dropping the response packets we're expecting to see from Microsoft. I think the only way we're going to get any further is if we install a packet sniffer on the DNS Server.

Wireshark would be good: http://www.wireshark.org/

I suspect we'll see the request head off to the MS Servers, but that we won't see a response. If possible it would be good to watch the same traffic on the Firewall, so we can see if the query goes out properly, and if a response comes back in correctly.

Chris
0
 
Keith AlabasterEnterprise ArchitectCommented:
Chris, wasn't there something about this (ms site lookups) way back in 'the good old days' when using root hints? I won't use root-hints anymore and always use forwarders; have done for about 20 years or more. I know there is a fine reason for it but old age means I can't recall what it was. This may have been it......
0
 
Chris DentPowerShell DeveloperCommented:

Hey Keith :)

I would be lying if I said I'd heard of that. Not really sure I've been in the industry long enough (certainly haven't at this level) :) That said, the only reasons I've discarded the Name Resolution Process to drop back on the network side are:

The server can correctly resolve the Name Server Records (from the Parent, TLD, Servers). So it's a long way further on than Root Hints.

It can also, if encouraged, resolve the rest of the nested CNAME's to get to the correct answer if it skips that one step chatting to the MSFT Servers.

When using Forwarders or sending the query directly to the MS Servers it resolves. To me that suggests one of two things.

Either the Request (UDP Packet) isn't passing through the Firewall / Router (or beyond) and never hitting the MS Servers. Or the Response is being dropped at the Firewall / Router or as it hits the Server.

Any other thoughts? Or can you see any holes in my reasoning?


LA0283,

Did we ever try turning off EDNS advertising on the DNS Server side? I think we should, just in case. You'll need the Microsoft Support Tools installed, then:

dnscmd /Config /EnableEDNSProbes 0

What version is the IOS (erm, it is IOS isn't it :)) on the PIX? Think it was 6.2 and above to get support for the DNS protocol fixup.

I know it's looping back to the beginning again, but want to make sure we're not missing something silly.

Chris
0
 
LA0283Author Commented:
above dnscmd states bad syntax...
C:\>dnscmd /Config /EnableEDNSProbes 0
Unknown Command Specified -- type DnsCmd -?.
Command failed, 87.

C:\>dnscmd /?
usage:  DnsCmd SrvIpAddress Command [Command Parameters].
Commands :
    GetServerInfo
    ResetListenAddresses
    ResetForwarders
    GetStatistics
    ClearStatistics
    EnumZoneHandles
    EnumZoneInfo
    GetZoneInfo
    CreateZone
    DeleteZone
    PauseZone
    ResumeZone
    ResetZoneType
    ResetZoneMaster
    ResetZoneMaster
    EnumNodeRecords
    EnumChildNodesAndRecords
    (null)

Our PIX-515E, 128 MB RAM, CPU Pentium II 433 MHz has IOS v6.3(4) which uses
fixup protocol dns maximum-length 4096
help document states...

Domain Name System (DNS) is a service that translates IP domain names to IP addresses.
Fixup DNS enables you to use UDP EDNS packets greater than 512 bytes as specified in IETF RFC 2671.

Field Descriptions
Enable Fixup DNSEnables DNS (EDNS0) service.
Maximum LengthSpecifies packet lengths up to 65535. The default is 512 bytes.
ApplySends changes made in PDM to the firewall and applies them to the running configuration. Click Save to write a copy of the running configuration to Flash memory. Use the File menu to write a copy of the running configuration to Flash memory, a TFTP server, or a failover standby firewall unit. See Configuration Changes.
ResetDiscards changes and reverts to the information displayed before changes were made or the last time you clicked Refresh or Apply. After Reset, use Refresh to make sure that information from the current running configuration is displayed.
0
 
LA0283Author Commented:
Well I think the problem is solved or rather a work around for PIX firewall, ie I started to think about what Chris said "Either the Request (UDP Packet) isn't passing through the Firewall / Router (or beyond) and never hitting the MS Servers. Or the Response is being dropped at the Firewall / Router or as it hits the Server."

I had yet another problem with inside client of PIX to establish VPN to outside world -- it refused to work until I finally mapped a public IP address with inside client.   So I did similar with DNS, ie mapped public IP address to Microsoft DNS and low and behold the lookup for www.msn.com and www.microsoft.com are both working without forwarders enable.  Still I'm not sure why (if that be UDP) packets are dropped for standard NAT client nor why other websites did not have same problem.  Anyway, I'm satisfied with results -- ie band-aids are either using DNS forwarder or mapping public client to physical public IP address.  And now I need to look into upgrading PIX to version 7.0 which will undoubtedly a new set of undocumented features (ie bugs).  

Thanks for your assistance and other insightful hints,
Wesley
0
 
Chris DentPowerShell DeveloperCommented:

Well that's extremely odd... would be very interested to know if an upgrade of the PIX OS manages to fix that.

Chris
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.