Make your application DHCP recognizable like SQL Server instances

Question

As you people know that you can easily identify systems in your network that are running SQL SERVER INSTANCE but is this possible that I can force DHCP to recognize my application?

example: I have many clients and a single server. but in secure networks out-bond traffic and port listeners are blocked. so I am trying to use reverse model.

I am successful in getting information about all the leased IP through querying DHCP but I want that my clients can query DHCP that where is my server and I want this without having access to DHCP server.

Scenario#1: Server Running on: 192.168.3.245 DHCP: 192.168.3.1 when my client application runs on some machine it query DHCP about the server and DHCP should tell him that your server is running @ 192.168.3.245

Answer 1

Sql Server doesn't use dhcp for this.

You can configure something called "scope options" in windows dhcp servers (and others) to send additional information with a dhcp request, but the client has to know to look for that information, and the dchp server has to support it. And the trick is that when I say "client", I mean the dhcp client program itself that's built into your operating system, not a a client program that you get to build. Also, not all dhcp servers support this, and those that do don't support dynamic registrations from outside apps like sql server. You have to configure it all up front.

An example of this is the IP phone system where I work. We set up custom options in dhcp that have information about where the IP PBX is located and what VLAN to use, and the dhcp client built into the phones knows how to read that.

Instead, I believe what sql server does is that whenever you try to find sql server instances on the network you send out a UDP broadcast packet, and any listening sql server will respond to that packet to announce their presense.

Answer 2

You can add a custom option field to most DHCP servers to transmit the information; but, many dhcp clients will discard any fields they are not specifically written to handle.

SQL Server actually has a different network socket which responds to UDP broadcast packets and provides the information about its instances. The client doesn't actually read SQL Server information from the dhcp client or any field the dhcp client handles.

Since the client will likely discard a field it doesn't support; odds are you would have to modify the dhcp client to process and store the field. That's before your application's client could possibly read the stored / obtained value. Modifying a dhcp client is typically an option only on Linux, and even then it's very hard to actually deploy modified clients without buy-in from the users, their admins, etc.

If the client can't ask / probe, then better to have them type in the config manually. If people don't like that, then tell them to allow the client to probe (which means they need to give you an infrastructure where it is possible).