none
[DNS NAME RESOLUTION FAILING on Azure WebSites]

    General discussion

  • This one is simple to explain but hard to believe...

    Quoting from Kudu

    d:\home\site>nslookup www.sapo.pt
    DNS request timed out.
        timeout was 2 seconds.
    Server:  UnKnown
    Address:  10.20.202.14

    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.

     d:\home\site>echo %computername%
    RD00155D8044CC

    I had to change DNS to IP on the references to my DB servers.

    Any idea why this keeps hapenning?

    Thanks

    Friday, November 29, 2013 10:59 AM

All replies

  • 1h later and it's still not possible to use DNS from within Azure WebSites

     

    D:\home\site> nslookup www.microsoft.com
    DNS request timed out.
        timeout was 2 seconds.
    Server:  UnKnown
    Address:  10.20.202.14

    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.

    Is anyone having this issue as well?

    Friday, November 29, 2013 11:55 AM
  • 3h 20m after, DNS is still not working on Azure WebSite

    nslookup www.sapo.pt
    DNS request timed out.
        timeout was 2 seconds.
    Server:  UnKnown
    Address:  10.20.202.14

    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
    DNS request timed out.
        timeout was 2 seconds.
     

    Friday, November 29, 2013 2:24 PM
  • Out of frustration for lack of response from Azure Team, let's see if the competition is faring better...

    nslookup www.sapo.pt 8.8.8.8
    Server:  google-public-dns-a.google.com
    Address:  8.8.8.8

    Name:    www.sapo.pt
    Addresses:  2001:8a0:2104:ff:213:13:146:140
     213.13.146.140


    Yes, Google's Public IP DNS servers are working fine.

    J

    Friday, November 29, 2013 2:26 PM
  • I think the nslookup command is simply not supported from within an Azure Web Site. However, this does not imply that DNS resolution is not working.

    I just verified this using Kudu Console:

    • If I run 'nslookup www.sapo.pt', I get the same as you
    • If I run 'curl www.sapo.pt', it works fine and downloads the page, which shows the DNS resolution is working fine.

    Hope this helps,
    David



    • Edited by David Ebbo Saturday, November 30, 2013 5:08 AM
    Saturday, November 30, 2013 5:04 AM
  • Hi David,

    Thanks for the feedback.

    We detected this issue when our app stopped working, complaining they could not resolve the name of the database server (in this case a ClearDB service) and a VM.

    After checking DNS records, we decided to change config settings back to IP, and it all went back to working.

    As to nslookup being supported, as you can see by the example we mentioned before, it works perfect if we specify a different server.

    of nslookup www.sapo.pt 8.8.8.8
    Server:  google-public-dns-a.google.com
    Address:  8.8.8.8

    Name:    www.sapo.pt
    Addresses:  2001:8a0:2104:ff:213:13:146:140
     213.13.146.140

    However, since we don't have a way to change configs of this server, we got stuck. 

    At this moment, we are unsure of when it will be safe to return to use DNS in this host.

    Thanks,

    Joao


    Saturday, November 30, 2013 8:34 AM
  • The fact that nslookup doesn't work is most likely unrelated to your issue. It's something that has probably never worked in Azure Web Sites, and the fact that passing an explicit DNS server allows it to work does not change that. So it is best to keep nslookup out of the discussion here.

    Were you able to verify that DNS resolution now works, e.g. by using curl? If that works, what issue are you running into now?

    Saturday, November 30, 2013 5:43 PM
  • Dear David.

    You are correct. nslookup is not the issue.

    The issue is that our site stopped working because PHP running on the IIS could not translate the DNS names to IP addresses.

    And this is the problem that went away once we changed our configs to access the DB via IP instead of DNS.

    Now, we could not do that for some external servers (such as the ones related to login from facebook and other social sites).

    And, as you can imagine, having to configure external addresses via IP is not desirable.

    It may well be that nslookup is not supported but there is a strong correlation between our unablity to resolve names and the fact that the default DNS server (which is chosen by nslookup) fails to respond.

    And, from what we have seen, the problem is not with nslookup but with the fact that one of the configured DNS servers seems to be failing.

    Thanks,

    Joao

    Saturday, November 30, 2013 5:53 PM
  • Hi Joao,

    I really do not think that nslookup not working has any correlation with your issue. Your issue was apparently temporary, since you seem to say that it had worked before and then stopped working for some time. But nslookup would never have worked, on any WAWS server. That has nothing to do with a DNS issue.

    Are you still having the issue right now? Can you please try the curl test I mentioned above? We need to understand if this is an ongoing issue. And please do not use nslookup as a way of trying to test it, as you will not get any useful info.

    thanks,
    David

    Saturday, November 30, 2013 6:08 PM
  • Hi David,

    The issue is no longer occurring.

    Now, regarding the future, I'm affraid my trust in Azure WebSites as the right platform for us is even lower than it was before.

    Please note that we had excelent experiences with CloudServices and VMs, but WebSites is not up there yet. 

    As to nslookup, i'm sorry but I still don't understand why you say it should not be used as an additional troubleshooting tool. It doesn't make much sense especially when it works with an external DNS address (either google or level3) and not with the internal DNS. 

    Thanks,

    Joao

    Monday, December 02, 2013 3:14 AM
  • Hi Joao,

    A tool is only useful to diagnose a condition if it produces results that reflect the condition. In this case, running nslookup from Kudu console will fail 100% of the time, regardless of the status of the DNS. Hence it does not have any value as troubleshooting tool here.

    As for your original issue, glad to hear you are no longer seeing it. If you see it happening again, please reactivate this thread so we can investigate further. You can also use curl from Kudu Console as a troubleshooting tool, as per my previous message.

    thanks,
    David

    Monday, December 02, 2013 5:49 PM
  • Hi David,

    We are having issues again...

    2013-12-03UTC17:09:36.000000  "mysqli_connect(): php_network_getaddresses: getaddrinfo failed: No such host is known. 
    2013-12-03UTC17:09:36.000000  "mysqli_connect(): (HY000/2002): php_network_getaddresses: getaddrinfo failed: No such host is known. "

    Since I am trying to connect to a server that is on azure (one of CloudLabs MySQL machines) using a CNAME, I cannot use Curl to test.

    But from the messages above it continues to look like a DNS resolution failure.

    And, as you can imagine, it's the 2nd day we are having our app down because of this.

    Thx

    J

    Tuesday, December 03, 2013 7:59 PM
  • Hi Joao,

    One thing we need to understand is whether it's failing to access the DNS altogether, or if the DNS server is responding, but is failing to resolve those specific names.

    Doing the curl test would help tell apart the two cases. e.g. try doing the curl test on some random other site.

    David

    Tuesday, December 03, 2013 8:20 PM
  • Also, I don't think the fact that the server is on Azure means you can't do the curl test on it. It should at least get thought the DNS resolution. So to isolated, it's worth trying curl with both that server and some other one (e.g. bing.com).
    Tuesday, December 03, 2013 9:33 PM
  • Dear David,

    The rationale for curl makes sense.

    Unfortunatelly today we got back to the same DNS issues...

    2013-12-04 08:56:01 mysqli_connect(): php_network_getaddresses: getaddrinfo failed: No such host is known.
    2013-12-04 08:56:01 mysqli_connect(): (HY000/2002): php_network_getaddresses: getaddrinfo failed: No such host is known.

    If you are interested, I can send you the target CNAMES for you to try to troubleshoot.

    For us is no longer of much interest since we are in the process of moving the site to something where we can have the control to change and prevent this. But maybe it can benefit someone else

    J

    Wednesday, December 04, 2013 12:06 PM
  • It would likely be hard to make progress without having more info about what your code was doing, and knowing the curl behavior during the issue time. I think we can close this for now if you don't want to to pursue the investigation.
    Wednesday, December 04, 2013 4:05 PM
  • Hi David,

    The messages are from PHP log files of attempts to connect to MySQL.

    At the time they occurred I was not able to test with curl.

    If you want, I can send you the target CNAMES in the mail.

    Thx

    Wednesday, December 04, 2013 5:13 PM
  • Hi Joao,

    Sounds good. My email is david.ebbo (at) microsoft.com.

    thanks,
    David

    Wednesday, December 04, 2013 5:14 PM