DNS names in masternode.conf

[martinf]

Hi,

I've tried using DNS names in masternode.conf, but with no luck. Seems to require IP:s. Is there any good reason for this?
The -dns command line switch is only for -addnode, -seednode and -connect

I guess it may be related to the static IP requirement for a masternode. I never understood that requirement. Is it because currently there is no way for a masternode to tell the network it has shown up with a new IP?
I read ppl should wait 60 minutes to let their node fall off the list before relaunching with new IP.
Anyway, it should still be possible to have DNS lookups for masternode.conf entries, right?

Thanks!

 

[moocowmoo]

I've tried using DNS names in masternode.conf, but with no luck. Seems to require IP:s. Is there any good reason for this?

The signed masternode "start", or announce as I call it, is passed from node to node and cached in ram.
Requiring each node to look up the ip of each message adds unnecessary overhead and opens up potential vectors for abuse and entry contention in the case of dns propagation issues. Accidental or otherwise.

Is it because currently there is no way for a masternode to tell the network it has shown up with a new IP?

Yes. The creation of a valid masternode announce (start) requires signing by the funding transaction private key. Moving to a new ip would require signing the updated announce. Something you certainly don't want floating around on a machine on the internet. Not to mention the new announce would be ignored until the entry matching the collateral vin is no longer in the cache.

I read ppl should wait 60 minutes to let their node fall off the list before relaunching with new IP.

70 minutes is the expiration time, but I usually tell people 90 just to be sure.

 

[martinf]

The signed masternode "start", or announce as I call it, is passed from node to node and cached in ram.
Requiring each node to look up the ip of each message adds unnecessary overhead and opens up potential vectors for abuse and entry contention in the case of dns propagation issues. Accidental or otherwise.

Would it make sense to still support DNS in the config file, i.e. do DNS lookup and use the IP thereafter when sending broadcasts etc?

So, my use case is that I have a static IP on my server, however, that IP depend on what VPS I choose to fire it up on. A dynamic DNS is updated as the server boots. I would like to eliminate places where I have to hard code the IP.

 

[flare]

Would it make sense to still support DNS in the config file, i.e. do DNS lookup and use the IP thereafter when sending broadcasts etc?

So, my use case is that I have a static IP on my server, however, that IP depend on what VPS I choose to fire it up on. A dynamic DNS is updated as the server boots. I would like to eliminate places where I have to hard code the IP.

Might be a improvement for UX to support FQDN in masternode.conf and IP lookup before signing the mn broadcast message. Message format would still contain IPs, but the user could use FQDN in his config file.

Thoughts @UdjinM6 ?

 

[crowning]

Might be a improvement for UX to support FQDN in masternode.conf and IP lookup before signing the mn broadcast message. Message format would still contain IPs, but the user could use FQDN in his config file.

Thoughts @UdjinM6 ?

I'm not Udjin nor do I play him in films, but in the case a server has several IPs under one name you'd only be able to start 1 Masternode on this server.

There might also be issues resolving hosts with both IPv4 and IPv6 interfaces, e.g. I have one which always returns the IPv4 address when asked.

I'm not against FQDNs, but it needs some thorough testing.

And, in case you live in a not-so-democratic country, a nameserver you trust.

 

[UdjinM6]

Might be a improvement for UX to support FQDN in masternode.conf and IP lookup before signing the mn broadcast message. Message format would still contain IPs, but the user could use FQDN in his config file.

Thoughts @UdjinM6 ?

I would avoid adding another layer of possible errors here and would like to keep signature creation and code around it as straightforward and deterministic as possible.

 

[flare]

I would avoid adding another layer of possible errors here and would like to keep signature creation and code around it as straightforward and deterministic as possible.

I agree - on second thought this might bring in more issues than benefit, especially that there is not a guaranteed 1:1 mapping between FQDN and IP.