Use handshake's NS record instead of GLUE4 (as needed)

[rithvikvibhu]

Currently, handout requires the name server to be available at a static IP address. This isn't always possible and will require a change on the blockchain to update the IP. This also takes time to update.

It's possible to have dnssec with a regular NS record pointing to a hostname (outside the handshake name).

Would be great if handout could take a hostname (like below) as name server and export an NS or GLUE4 (GLUE4 if IP, NS if hostname).

Example of this config: https://bb-8

It has 1 NS record and a few DS (1 is enough):

{
  "result": {
    "records": [
      {
        "type": "NS",
        "ns": "blek.centralus.cloudapp.azure.com."
      },
      {
        "type": "DS",
        "keyTag": 61521,
        "algorithm": 7,
        "digestType": 2,
        "digest": "e1cee5173d37ab458e0d6ac74fcb58ee1d162c8510ac94df4d9ac50c0b47e2c7"                                                                  
      },
      {
        "type": "DS",
        "keyTag": 51384,
        "algorithm": 7,
        "digestType": 2,
        "digest": "0bfd24088a4569635c2cd596d4d7663ac9fc9961e189eb755b9e2fb4035ca9c1"
      }
    ]
  },
  "error": null,
  "id": null
}

[pinheadmz]

There's a lot I want to do with handout, most importantly refactoring it as a library that can be required instead of being a self-contained app (all my handout sites are branches of this git repo 😦 instead of separate projects). I made it intentionally to be super simple one-command self-hosted website for HNS TLDs and as a result it is not very flexible yet.

It was also important since we don't allow A records on chain like a lot of users expect (this was allowed on testnet)

However, you can do what you're asking without modifying the code. Just run hnssec-gen.js normally (with the IP of the handout server, especially whatever A record you want served for your website) but manually edit the GLUE4 record down to an NS, or whatever you want to put on chain (handout doesn't care). In your above example if you were hosting the handout server at blek.centralus.cloudapp.azure.com. I'm pretty sure everything would work fine.

You can also edit the handout.conf file generated by hnssec-gen.js at any time, and then just relaunch handout.

If you need to host the nameserver and webserver on different machines - eh - use BIND9 and Apache ;-) (for now)

[rithvikvibhu]

I'm using bind9 right now + nginx (which should also take care of the DANE name check issue from telegram).

Wouldn't calling hnssec-gen.js with different IPs generate different DS records and zone files? Zone files I get, they have to be updated. But DS changing will be a problem as they go on-chain.

In my case, I have bind9's auto signing enabled so every time I start the vm, I edit the zone file with the new public IP address, increment the serial number and simply reload bind9. It takes care of resigning all records. And the same DS records work as KSKs are reused.

[pinheadmz]

The IP address passed to hnssec-gen is only really used in the SSL cert it generates (added to Subject Alt Name -- and that's only because I wanted to be able to https:// to my IP without using a URL). It is also passed to the handout.conf file which is then parsed by the AuthNS to generate A records. So the DNSSEC keys and DS records generated by the script can be reused at any IP address. You can always update the IP address in handout.conf and restart the combo server.

[rithvikvibhu]

Ahh okay. So a startup script that edits handout.conf with a new IP should be enough. I don't need https over IP, so won't be calling hnssec-gen again. Will try this out, thanks