dns_get_record is failing when used in a webpage, but works when called from the command line

[merk]

Hi all,

In the process of moving websites off an old win 2008 server and onto a new win 2016 server. I discovered that dns_get_record is failing on the new server. I made a simple test page:

$dnsrecs = dns_get_record('google.com'); 

When i call this as a webpage, it comes back with dns query failed. It comes back instantly, so it's not like it's timing out. But, if i just call the webpage from the command line, it comes back with the dns record. Why would dns_get_record fail when used in a webpage, but work from the command line?  I can make outside connections since I was able to send an email to an smtp server. I thought maybe this is a permission issue, but seems odd I'd be able to send an email using php but not do a dns query.

Oh, and I have two versions of php installed on this server - 5.4.10 and 7.4.9. The old version is a direct copy from the 2008 server. 7.4.9 is a clean install. Both of them behave the same way. webpage fails, command line works. Also, nslookup works. I also tried switching to using google's name server, but it had no effect on anything.

Anyone have any suggestions? 

[requinix]

Have you checked error logs? Perhaps there's a "DNS Query failed" error? And are you sure it returns literally false and not an empty array?

[merk]

I've set display_errors to on so i can see what's happening. 

Warning: dns_get_record(): Dns Query failed in test.php on line 47
PHP Warning: dns_get_record(): Dns Query failed in test.php on line 47

The other lines in this file are irrelevant since I've commented them all out. The only code executing is the one line of code I included in my original post.

[merk]

I made some progress. Since it felt like this was some sort of permission issue, i decided to add the app pool user to the admin group. When i did this and then ran the webpage, it worked. Surprisingly, it kept working even after i removed the user from the admin group. It even works on both versions of php now. My guess is it needed to write to some temp/cache file that did not exist and it did not have permission to create the file. When I added it to the admin group, it was able to create the file. And it has sufficient permission to write to the file without being in the admin group.

But that's just a guess. If anyone has any ideas as to what the specific problem was please let me know, so I can be sure it's really fixed.

Thanks

[requinix]

PHP uses DnsQuery_A to perform the DNS lookup, but the documentation doesn't mention requiring any specific permissions.

Was the pool running as an underprivileged user? Does it have network access? Could you do other networking things like access remote URLs with file_get_contents()?

[merk]

I had already thought of it not having network access but i ruled that out since I was able to send an email. Not being able to send an email is what started me on all this in the first place since the email was failing to send since it wasn't able to resolve the mailserver's hostname. I just tried using file_get_contents for the hell of it and it worked.

Can you think of any sort of temp/cache file that might be used doing a dns query? Because that's the only scenario i can think of right now where it would start working after running under an admin account, but then keep working even after it's no longer running as an admin. If it were a network access issue, then it should have stopped working after i removed it from the admin account. 

The account the app pool is running under now is just part of the users group. I also tried running it under one of the default app pools just in case i did something when i created my app pool, but it behaved the same no matter which pool it was running under.

[requinix]

2 hours ago, merk said:

I had already thought of it not having network access but i ruled that out since I was able to send an email.

2 hours ago, merk said:

Not being able to send an email is what started me on all this in the first place since the email was failing to send since it wasn't able to resolve the mailserver's hostname. I just tried using file_get_contents for the hell of it and it worked.

Which is it? Was it sending emails or was it not sending emails?

Was it ever in a state where the hostname could not be resolved (reproducibly, not just once) but stuff like file_get_contents on a remote URL did work? Because both of those involve DNS.

 

2 hours ago, merk said:

Can you think of any sort of temp/cache file that might be used doing a dns query?

No, the filesystem is not involved with DNS queries.

[merk]

Sorry for being confusing - initially, i was unable to send email. I thought the problem was with the code for sending the email, and then eventually realized it wasn't resolving the mail servers hostname. Which is what led me to discover the dns query wasn't working. I was able to send email by using the mail server's IP address. Which is how I tested if php was able to make any outgoing connections.

As far as I know, the only function I tried which would have resulted in a dns query was sending email, when it tried to resolve the smtp hostname. And me testing dns_get_record directly. 

If you are sure there's no sort of cache or temp file that's written to, then I'm pretty much stumped as to what's going on. I can't think of a scenario where running it just once as admin would fix it.

[requinix]

If email worked by IP address then yes, it wouldn't be a networking problem.

Is the server multihomed?

[merk]

Yes i suppose it is - it was setup this way by the host (it's a virtual godaddy server). There are two network adapters - a virtual ethernet and something called 'floating ips' which is a loopback address. You think the dns query might have been trying to use the wrong interface?

[requinix]

That could explain it. Windows doesn't really like to be multihomed.

Any reason you have to dns_get_record to begin with? Why not use the hostname directly when sending the email?

[merk]

no, no reason i can't just use the IP address for email. But it's not just that - there might be other bits of code somewhere that need to resolve a hostname. That just happened to be the first thing i was working on and noticed the error. Plus I just don't like not knowing why something relatively basic like that wouldn't work - or would only work when you run it as admin once.

[requinix]

Not the IP address. The hostname. It sounds like you were saying you did dns_get_record to lookup the hostname and give that to the mail stuff - what I'm wondering is why you can't give the hostname to the mail stuff. Why you have to look it up yourself.

And to be clear, multihoming is my best guess. IIRC there is a way to configure Windows to prefer one interface for certain things but it's not perfect.
The obvious test would be to disable the other interface and see what happens.

If you absolutely must do your own DNS lookups, grab a library that does DNS but that also lets you specify the outgoing interface (by name or bound address) for the lookup. Pretty sure there's going to be one out there.

[merk]

ah - sorry for the confusion again. I was not using dns_get_record with email - after i realized the built in smtp functions weren't able to resolve the hostname, I then used dns_get_record to test resolving the hostname on my own and then that's how i found out it was actually the dns lookup that was failing and not something specific to the smtp functions.

[requinix]

Ah, that makes a lot more sense.

For the library, Net_DNS2 is an option.

[merk]

thanks - so far i don't need a 3rd party dns library but I'll hang on to it. If i ever figure out what the issue was, I'll try to remember to come back here and post an update.

[merk]

well, one more update - someone else asked if restarting IIS would do anything - it broke it again. Only now running it under an admin account didn't do anything this time. So now i really have no clue at all why it worked once as admin and now it doesn't.

[merk]

one more update - i found a reliable way to reproduce the temporary fix, and to break it again. Adding the app pool user to the admin group AND running iisreset will fix it. But only IISRESET. Stopping and starting IIS using the iis control panel doesn't do anything, nor does recycling the app pool. I can switch the user back to a regular user account and as long as i don't use iisreset, it will keep working. Once I run iisreset, it'll stop working until i add the user back to the admin account and reset again. 

I tried running iisreset a few times without making any changes to the app pool user account, and it didn't change behavior unless i changed the account type of the app pool user.

I'm not sure what is different between running iisreset and using the stop/start function in the iis control panel, but there's something going on there.