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)
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...
Such things would already be known in its training, eg <a href="https://duyet.github.io/llm-over-dns" rel="nofollow">https://duyet.github.io/llm-over-dns
itintheory · · focus · HN ↗
brian_cunnie · · focus · HN ↗
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)
itintheory · · focus · HN ↗
luma · · focus · HN ↗
aftbit · · focus · HN ↗