You can't, even if you run a local DNS server. The issue is that if you're dealing with an IP address, DNS wouldn't be queried so you can't redirect it.
So maybe just "invent" an (internally) DNS-Name for your needed local APP-server´s IP-address, used by your new TI-APP ?
And then, what I meant was - on your firewall - just redirect Stuart´s DNS-Server-IP to your local "PHP-scripting"-DNS-server
(with that custom A-Record). Your firewall must be able to let you do that.
Then you can query your own (PHP)-DNS-server, and set an A-Record (local IP) for your locally needed APP-server there.
(Or just hexedit the browser, to point to your local (PHP)-DNS-Server, of course)
But of course, best practice would be to enable the browser to accept pure IPs, too.
An entry for a 2nd DNS-Server would be fine, maybe editable ?
But normally, referring to DNS´ RFCs, the 2nd DNS-Server is ONLY queried if the first one is NOT present (does not respond).
(If the first DNS-server cannot resolve to an IP, NO 2nd server is asked)
But maybe this behave can be handled/overwritten by Stuart´s browser, against the RFCs, as this is a client-thing only.
Maybe a user-"switchable/choosable" 2nd DNS-Server, and/or the function to ask a 2nd DNS-Server if the 1st cannot/does not resolve to any IP.