Server Status Checker Opinions

#1

I just finished re-writing the server status checker in a much better fashion, but still can’t come up with a good solution to a problem that I’ve always had, so I’m hoping one of you have good ideas.

As you know, people can put a hostname for their server address, each time I check the servers I resolve the hostname to an IP and save that as well. This allows me to stop new people from registering IP addresses that other servers already point to, which works fine. Here are some simplified examples:

[table]
[tr]
[td]id[/td][td]hostname[/td][td]resolvedIP[/td]
[/tr]
[tr]
[td]1[/td][td]bob.com[/td][td]5.5.5.5[/td]
[/tr]
[tr]
[td]2[/td][td]tom.com[/td][td]6.6.6.6[/td]
[/tr]
[/table]

Which of course is fine, and if someone tries to register ‘alan.com’ which resolves to ‘5.5.5.5’ I see that is already registered to bob.com so I don’t allow it.

The problem happens when I am checking if the currently registered servers are online, if domains are re-pointed they may look like this:

[table]
[tr]
[td]id[/td][td]hostname[/td][td]resolvedIP[/td]
[/tr]
[tr]
[td]1[/td][td]bob.com[/td][td]5.5.5.5[/td]
[/tr]
[tr]
[td]2[/td][td]tom.com[/td][td]5.5.5.5[/td]
[/tr]
[/table]

Now the naive approach is to say since bob.com was registered first, give it preference and say tom.com is offline even though it isn’t. That is the fair thing to do in this case, but then you come across a change like this instead:

[table]
[tr]
[td]id[/td][td]hostname[/td][td]resolvedIP[/td]
[/tr]
[tr]
[td]1[/td][td]bob.com[/td][td]6.6.6.6[/td]
[/tr]
[tr]
[td]2[/td][td]tom.com[/td][td]6.6.6.6[/td]
[/tr]
[/table]

Now bob.com gets to use tom.com’s uptime, while kicking them ‘offline’, so that isn’t fair.

I used to delete all servers that resolved to the same IP, which is fair if it’s one guy posting them all, but isn’t for competing servers posting a dual advertisement for an enemy and getting their server deleted.

So, can anyone come up with a GOOD or even a DECENT solution to this problem? If I don’t get a good discussion going on here, I may move this topic to the public, just a fair warning. :slight_smile:

#2

Don’t let people change IP’s to one that has already been taken (resolved or not)?

If someone registers an IP, and it’s online, they have verified that they own the server there (unless they register someone elses IP before they can, which is unlikely)

Thus switching to one that has already been taken is not plausible in a legitimate case that I can think of

#3

I don’t have control over the changing, the hostname they have registered (like ‘bob.com’) doesn’t change, and has already been verified as being owned by the poster, but they can point it to whatever IP (like ‘5.5.5.5’) they like whenever they like. Hence the problem.

#4

I know but you can check if it changes whenever you check uptime. If it changes, ‘disable’ their advertisement (deleting would get annoying) and give them a message when they go to server control panel, maybe have it send them an email to their moparscape account email and a private message, etc. Then just check it again whenever the normal online checks are done, and if it’s back to an unregistered IP re-enable the advert

#5

So disable it every single time the IP changes? What about dynamic IPs?

Or are you saying only disable it every time it is changed to an already-registered IP?

#6

Yea I meant if it’s changed to an already registered one :stuck_out_tongue:

[quote=“Davidi2, post:4, topic:434907”]if it’s back to an unregistered IP re-enable the advert[/quote]Forgot to put that at the start too

#7

What if they own that IP though? So I should give them the opportunity to verify it? And if they do verify they own it, what should be done with the other server squatting on their IP?

Finally, what if, say, bob.com and tom.com have different IPs, and during one run, they both change their IP to the same IP. Which one gets priority? Or just give them both the chance to verify and disable the other? What if they both verify that they own the IP? (like a shared box, or a developer and owner both posting the same server?)

This is hurting my head…

#8

[quote=“Moparisthebest, post:7, topic:434907”]What if they own that IP though? So I should give them the opportunity to verify it? And if they do verify they own it, what should be done with the other server squatting on their IP?

Finally, what if, say, bob.com and tom.com have different IPs, and during one run, they both change their IP to the same IP. Which one gets priority? Or just give them both the chance to verify and disable the other? What if they both verify that they own the IP? (like a shared box, or a developer and owner both posting the same server?)

This is hurting my head…[/quote]Don’t you already have methods to prevent that? Like it needs to be posted from the IP you put in? You could have it so that whenever the IP changes they need to do that again (disabling it in the meantime) until they verify that they own that IP. In the case of two co-owners posting the same IP, just go first come first serve. Whoever can verify first gets it, and the other gets disabled. We don’t wanna get mixed up in any of that stuff, right? :slight_smile:

#10

[quote=“Davidi2, post:8, topic:434907”][quote author=Moparisthebest link=topic=537627.msg3931554#msg3931554 date=1330725809]
What if they own that IP though? So I should give them the opportunity to verify it? And if they do verify they own it, what should be done with the other server squatting on their IP?

Finally, what if, say, bob.com and tom.com have different IPs, and during one run, they both change their IP to the same IP. Which one gets priority? Or just give them both the chance to verify and disable the other? What if they both verify that they own the IP? (like a shared box, or a developer and owner both posting the same server?)

This is hurting my head…
[/quote]Don’t you already have methods to prevent that? Like it needs to be posted from the IP you put in? You could have it so that whenever the IP changes they need to do that again (disabling it in the meantime) until they verify that they own that IP. In the case of two co-owners posting the same IP, just go first come first serve. Whoever can verify first gets it, and the other gets disabled. We don’t wanna get mixed up in any of that stuff, right? :)[/quote]
Yes, I verify that the user that posted the server owns the IP that the hostname resolves to by connecting to my server from it. But of course that goes out the window afterwards because they can point their hostnames to whatever IP they like. So two different servers pointing to different IPs could both change to point at the same IP in one run, and I don’t know how to handle that one, suggestions?

They do have to register and verify they own the IP already, but when the hostname points to a different IP later I’m not sure how to handle it. That’s the reason for this thread.

edit:
For example, it just happened in the last update:

key: ‘new-ip’ value: ‘id,hostname,old-ip;’
key: ‘89.1.232.123’ value: ‘28141,justsopro.no-ip.info,70.247.172.11;25026,runeinsanity.no-ip.org,38.114.126.77’

Both of those hostnames point at this new IP, and it wasn’t the old IP of either one of them, how should this situation be handled?

#11

as far as shared boxes goes, perhaps check for port similarity?

#12

Do it so that it gives priority to the server with the hostname that resolved to the given IP address first. Every time you resolve a hostname, store it in a table:

CREATE TABLE hostname_resolution_log (
  server_id INT NOT NULL,
  resolved_ip VARCHAR(255) NOT NULL,
  port INT NOT NULL,
  resolution_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
  blacklisted BOOL NOT NULL DEFAULT FALSE
  PRIMARY KEY(server_id, resolved_ip, port, resolution_time)
);

Insert like so:

INSERT INTO hostname_resolution_log (server_id, resolved_ip, port) VALUES (147, '127.0.0.1', 43594);

To obtain the first server that resolved to a given ip, query like so:

SELECT server_id, resolved_ip, MIN(resolution_time) AS earliest_time
FROM hostname_resolution_log
WHERE blacklisted = FALSE AND resolved_ip = '127.0.0.1' AND port = 43594;

NOTE: This SQL doesn’t mention foreign keys, but the server_id field is supposed to be a foreign key that references the table that you store server data in. Also, if you only wish to support IPv4 then you can make use of an integer to store the IP address instead of a VARCHAR.

Hope that helps.

EDIT: Added port field, so that the issue with two servers sharing an IP address won’t be a problem.
EDIT2: Added blacklisting of rows - now you can simply blacklist all log entries for a server that needs to be removed/banned, which ensures that you won’t reach a situation where an IP address/port becomes unusable due to unremoved log entries.

#13

I don’t want to let two servers use the same IP, even with different ports. It’s just not practical.

@Lothy, but in my last example, in a single run (so at the same time) two hostnames resolved to the same IP. So how to resolve that?

#14

My approach works as long as a legitimate server exists before malicious users attempt to leech off its uptime. Whether it was created a year before, or just seconds before, a second server using the same IP address is irrelevant.

In my mind, this was the scenario that I came up with that solution for:

  1. Legitimate user registers server with hostname X which resolves to IP address Y. The IP address is resolved for the first time at the time of creation.
  2. Illegitimate user, at any later stage, registers a server with hostname Z which resolves to IP address Y. The IP address is resolved for the first time at the time of creation.
  3. Using the MIN function, you can obtain the earliest log entry for a given IP address that isn’t marked as blacklisted.

When your program runs, it makes a new insertion into this table for each server when it resolves the hostname, so you will always have that trail of IP address resolutions.

What I should have mentioned is that this approach works perfectly if you use it from the beginning. I suspect it will be tricky to implement now though if you don’t already have some form of auditing built into the system that will allow you to identify which servers first made use of which IP addresses.

#15

So then once a server uses one IP address it is blacklisted from being used again forever?

In your example, if Y is no longer used by X (or any other server), then Z should be able to use it, right?

As to what I am trying (but failing miserably) to explain, I’ll try your way.

  1. Server registers with hostname X which resolves to address Y.
  2. Server registers with hostname N which resolves to address Q.
  3. Now all of the sudden, both hostname X and N both resolve to previously unused address Z. What do I do here?

Here is actual output from the server checking program that includes some real-life examples:

1.
resolvedIP:         '89.1.232.123'
		id:         '28141'
		newServer:  'false'
		hostName:   'justsopro.no-ip.info'
		online:     'true'
		previousIP: '70.247.172.11'

		id:         '25026'
		newServer:  'false'
		hostName:   'runeinsanity.no-ip.org'
		online:     'true'
		previousIP: '38.114.126.77'

------------------------------------------
2.
resolvedIP:         '220.255.4.29'
		id:         '28783'
		newServer:  'false'
		hostName:   'battleroyale.gamespeakz.com'
		online:     'true'
		previousIP: '24.86.123.242'

		id:         '19937'
		newServer:  'false'
		hostName:   '220.255.4.29'
		online:     'true'
		previousIP: '220.255.4.29'

------------------------------------------
3.
resolvedIP:         '184.154.20.204'
		id:         '21666'
		newServer:  'false'
		hostName:   'genericx.no-ip.org'
		online:     'true'
		previousIP: '64.229.171.174'

		id:         '30234'
		newServer:  'false'
		hostName:   '184.154.20.204'
		online:     'true'
		previousIP: '184.154.20.204'

		id:         '28644'
		newServer:  'false'
		hostName:   'lethium.no-ip.org'
		online:     'true'
		previousIP: '173.32.113.9'

------------------------------------------
4.
resolvedIP:         '178.18.246.109'
		id:         '31782'
		newServer:  'false'
		hostName:   'bizaarpk.no-ip.org'
		online:     'true'
		previousIP: '93.186.168.220'

		id:         '37252'
		newServer:  'true'
		hostName:   'xbrutalpkz.zapto.org'
		online:     'true'
		previousIP: '178.18.246.109'

Now, in cases 2 and 3 it’s obvious who should ‘win’, the servers that use the actual IP and not the hostnames, because someone verified they owned that IP and it can never change. What should be done in this case though? Delete the other two servers? Disable them? or what?

Case 4 would be decided in favor of the second server because it previously resolved to that IP before the other server. The issue in this particular case is that the supposed ‘malicious’ server has already been posted, while the ‘new’ server is the one that looks legitimate. Ideas?

Case 1 is the tricky one I described above, what is the fair way to resolve this case?

#16

It sounds like your approach to cases 2 and 3 (which is to disable the imposters) is a fine solution. Someone has the IP address claimed, that’s the end of it.

My solution above should solve case 4 - if the second server resolved to the IP before the other server then it is logged as having resolved to that IP at an earlier time, and would be identified using that select query above.
The catch is that if someone knows which IP address a person will use and makes a page before them then we can’t detect that. Of course, we should be able to reasonably suspect that users can keep their mouths shut to avoid this problem. It’s not our job to deal with their in-fighting.

I can’t see a solution for case 1 if that output is from one execution of the server checking program.

As for blacklisting, you only blacklist the log entries based on the server id that those entries are for. That’s why the blacklisting occurs in the logging table that I’ve described, and not elsewhere.

For example, this query would blacklist all entries in the resolution log table for the server that you ban. If a new server was registered with the same IP address then those new log entries would not be blacklisted, and so they would be obtained by the select query given above.

UPDATE hostname_resolution_log
SET blacklisted = TRUE
WHERE server_id = 147
#17

How often does this kind of problem happen? If it’s not incredibly prevalent, I wouldn’t see the harm in making the status page generate a list of “conflicting” servers every 24 hours or so, and then you (or the staff) could contact the server owners querying as to why the conflict is happening.

#18

It actually happens a lot more than you would think really.

#19

I go through the first few pages of the status page every once in awhile and I usually end up deleting at least 5 servers that have been posted more than once.

#20

I went ahead and released this server checking code, and ended up not doing anything about this ‘conflict resolution’ as of yet. The code is on github if anyone is interested in seeing how they would do it.