It was my service that the agent used: nip.io / sslip.io
OpenAI emailed me to let me know that their agent used my service to break out of test containment. OpenAI was quite polite (shout-out to Steven), and let me know they'd keep the name of my service out of the blog post.
nip.io is a simple DNS service: when queried with a hostname with an embedded IP address, returns that IP address, e.g. 127-0-0-1.nip.io → 127.0.0.1
The nip.io service is airtight with one exception: the "_acme-challenge" subdomain. In that case, rather than returning the IP address (or whatever record was queried), nip.io would return an empty "answer" section but an NS authority & not authoritative. In other words, nip.io would delegate DNS queries to that IP address.
That was the escape hatch.
In a couple of weeks I'll close that escape hatch. It was originally intended as a mechanism to allow savvy uses to procure wildcard certs (e.g. "*.64-176-22-9.nip.io") from certificate authorities such as Let's Encrypt. But experience proved that the it was an undue burden trying to support unsophisticated users attempting to procure a wildcard cert. "Wildcard certs are not supported" became my new mantra.
But I had neglected to remove the old code.
(the late Roopinder Singh created nip.io, and he was a good guy. I miss him)
Can you tell us what the value is of a domain, where the IP is required to be known? Why not just use the IP?
Wow, such a tiny hole. Thank you for keeping it alive.
But that's still DNS, right? Where does it bleed over into an LLM API? I understand there are DNS to LLM server projects, but how would the agent discover one? And I'm guessing most people who run something like that don't expose it publicly...