Using XNS names

Once the I2P router and XNS Resolver are running, applications can use .xns names through the normal system resolver.

Test the complete path:

curl http://example.xns/

No I2P proxy setting is needed in curl. The application receives a synthetic address from XNS Resolver and opens an ordinary TCP connection. The resolver carries it through SAM to the extended destination derived from the XNS owner key.

Subdomains follow the same route:

http://example.xns/
http://indexer.example.xns/

The service must explicitly accept each Host value it intends to serve.

What the visitor trusts

The configured indeXer reports the current XNS owner key. XNS Resolver validates the response and address derivation, but it does not scan Monero itself. Users may choose another indeXer or run one locally.

I2P locates the encrypted LeaseSet2 destination belonging to the derived public identity. The changing blinded publication keys do not change the stable owner key or extended address.

Finding a failure

Test the path in order.

Query the indeXer:

./xns lookup \
  --indexer <xns-indexer-url> \
  example

Derive the expected address:

./xns-i2p address <owner-key>

On the publisher, compare this result with:

./xns-i2p inspect /path/to/service

Then open the i2pd console, select the service under Local Destinations, and compare it with Encrypted B33 address. Do not compare it with the ordinary 52-character address on the Server Tunnels page.

Check the SAM listener on the visitor:

ss -ltn | grep ':7656'

Check local XNS resolution:

getent hosts example.xns

It should return an address from the resolver's virtual range.

Finally:

curl -v http://example.xns/

If name resolution succeeds but the connection fails, check the SAM listener, encrypted LeaseSet2 publication and i2pd tunnel state. If the connection reaches the service but returns 404, the reverse proxy probably does not accept Host: example.xns.

On the publisher, verify the local backend separately:

curl -v -H 'Host: example.xns' http://127.0.0.1:<local-port>/

If nothing is listening on the configured host and port, the I2P destination may publish correctly while every incoming stream fails at the final local hop.

Reading i2pd

The I2P tunnels page confirms that the server tunnel was loaded. The Local Destinations detail page confirms the Encrypted B33 address and shows LeaseSets and tunnel state.

Useful logs are:

sudo journalctl -u i2pd -n 100 --no-pager
sudo tail -n 100 /var/log/i2pd/i2pd.log

Unknown section type means the tunnel type is invalid. XNS uses type = server. An address mismatch usually means the intended private.dat was not loaded; with the standard i2pd service layout, use a data-directory-relative key path such as:

keys = xns/private.dat

The complete route is:

XNS name -> Monero claim -> owner key -> extended I2P address
         -> encrypted LeaseSet2 -> local service

The ordinary destination hash may still be displayed and used by I2P software, but it is not part of the XNS derivation.