Error publishing Zonefile

Core Blockchain
#1

Hi,
I randomly keep on getting the following error message on the registrar.

{"level":"error","message":"Error publishing zonefile for tx 6084c5da8618ebdd64e7dafc4c68a55e00ac4d5b7da25c6445d22579b05ad9ec: Error: Zonefile not saved","timestamp":"2020-02-04T09:02:49.690Z"}

This leaves the subdomains in the zonefile non-resolvable ever after getting 6+ confirmations on the transaction. What is causing this error? What steps should I take to avoid this?

#2

Was the transaction accepted by Blockstack? If not, then the zone file won’t be either.

#3

I see the following logs on BNS against the transaction hash:

{ 
   "log":"[2020-02-04 02:47:28,634] [DEBUG] [namedb:532] (18.140718757353280) REJECT NAME_UPDATE at (615874, 865) data: __original_op_data__='{'value_hash': '32f491c25a28869b297aee73fc22ee9ef3175f7a', 'name_consensus_hash': 'fa2c6fa343189462aff918cb077c4095', 'sender': '76a91467f7f9424342a0f1ab222ebbc1fb0192d43fe8ab88ac', 'sender_pubkey': '02d5c858436ba3cc68e61bdee097c3e3548a00a64e5a5be01e81bce9c06f9a7ada', 'txid': '6084c5da8618ebdd64e7dafc4c68a55e00ac4d5b7da25c6445d22579b05ad9ec', 'opcode': 'NAME_UPDATE', 'address': '1AUjfGid6qpUo1WLWorEfarmapWMLY1BJR', 'vtxindex': 865, 'op': '+'}', address='1AUjfGid6qpUo1WLWorEfarmapWMLY1BJR', consensus_hash='None', name_consensus_hash='fa2c6fa343189462aff918cb077c4095', op='+', sender='76a91467f7f9424342a0f1ab222ebbc1fb0192d43fe8ab88ac', sender_pubkey='02d5c858436ba3cc68e61bdee097c3e3548a00a64e5a5be01e81bce9c06f9a7ada', txid='6084c5da8618ebdd64e7dafc4c68a55e00ac4d5b7da25c6445d22579b05ad9ec', value_hash='32f491c25a28869b297aee73fc22ee9ef3175f7a', vtxindex='865'\n",
   "stream":"stdout",
   "time":"2020-02-04T02:47:28.80811938Z"
}

Under what scenario does NAME_UPDATE gets rejected ?

#4

According to my logs, it was a stale consensus hash. A transaction needs to be mined within 24 blocks in order for it to be accepted.

The solution is to re-send the names that would have been included in that zone file, or simply re-send a NAME_UPDATE with the zone file hash and a higher fee. Make sure you’re getting a fresh consensus hash from your Blockstack Core node (and, be sure to run your own; don’t use core.blockstack.org for production).

#5

@jude We do run our own node https://bns.cruxpay.com. We verify ID resolutions( /v1/names calls) against both your and our node. We do this because the lack of a client-side SPV-like process makes ID resolutions essentially unverifiable. Cross verifying two independently controlled sources of information helps build trust here.

Is it a problem if we use core.blockstack.org in this manner? It’s important for our security model until we motivate our clients to run their own nodes. For some background, we’re working on CRUX Protocol - https://docs.cruxpay.com/docs/what-is-crux. Our clients are wallets & services who integrate our SDK

#6

Ah, cool! Thank you for running a public node :smiley:

I take it you’re running a subdomain registrar? Is your subdomain registrar configured to talk to your node, or to core.blockstack.org? It will only talk to one node, and it needs to do so in order to get the latest consensus hash in order to construct a valid NAME_UPDATE transaction.

The nodes behind core.blockstack.org are guarded from DDoS by CloudFlare, which also means that any responses you get back are potentially cached (which is risky for people who rely on it for subdomain registrars, since the consensus hash might be stale). Moreover, we had a minor incident earlier where one of the nodes behind core.blockstack.org was “stuck” and responding with stale data (this may have been the underlying cause if your subdomain registrar is using core.blockstack.org).

#7

Okay, we’ll try configuring the registrar to talk to our node and see how it goes :slight_smile:

1 Like