I need some basic ideas about what I am trying to conceptualize here ("IP spoofer")

A company that I know are producing some DNS server.
They want to have it performance tested.
I looked at their solution, it looks ridiculous on paper and performs ridiculously.

I want to make a proposal, but there's a part that I don't quite know how to even think about!

I know the DNS profiles they want to test, how to handle caches, the typical query type ratios...
But one key element is that the DNS server being tested must receive the DNS queries from different IP's!

Now, I am thinking: it's all going to one LAN socket in the server, right?..
Can there be some "magical box" (is it a "switch"? I know little about the hardware side of networking!) that spoofs the source IP's, as they go into the server?

So, I got a computer on the testing end, that's set up with my highly accurate and correct test, it dispatches DNS queries, wrapped in some data format that the "magic box" can read, this data format includes the DNS query and the IP to spoof the query "from".
The magic box prepares the data on the LAN cable, like the requests are coming from "all those different machines around the world".
The magic box will need to go the other way around, when it gets a response from the DNS server, it needs to wrap it in the data format, including the spoofed IP. So, that my test computer registers the test result (response time) to the correct request.

I was even thinking about an electronics implementation, a fast micro-controller that accepts the LAN cable on one side, reads the DNS request, changes the IP and passes on the augmented request to the server.

So, any ideas of things like that that already exist?
Or at least you could help me with terminology, as I am currently just calling it a "programmable switch" in my head and that could be totally wrong :D
Last edited on
you can set up a computer to BE a router (a switch and a router are similar, routers do more stuff). This is easier on unix than windows, or in my mind it would be.
Then your 'router' software can just bounce everything around with fake IPs, I don't know how hard it would be to set that up? But I suspect it is NOT difficult?
An old laptop or other defunct box can do this, by the way, as even a decade old machine can do more than a dedicated router can do. Its not rocket science.
tricksy part, I don't know if it would require a second computer or if you can make the one doing the testing do both things (easily). It can be done on one box, but that may take much more effort (or not) ... I do not know.
if all it does is play router, a usb boot disk or something instead of a reformat and reload may be all you need there too.
Last edited on
If you're using Fake IP's, as in crafting the packet from scratch, you need to run your NIC in "Promiscuous Mode" to catch everything across the local interface: https://en.wikipedia.org/wiki/Promiscuous_mode#:~:text=In%20computer%20networking%2C%20promiscuous%20mode,that%20the%20controller%20is%20specifically
Most drivers support that natively.

A no-less-crusty way might be to assign each NIC on the machine a list of IP addresses from a text file and roll through them with "AddIPAddress()" "DeleteIPAddress()" (WinAPI, I can't recall BSD offhand). You'd be constantly changing the static IP address of each port, then running your test and doing it again so have a subnet ready to prevent you from running over anything in production. I'd recommend a Hypervisor for this, pass each NIC through to dedicate it to an instance of a VM. Enterprise DataCenter would be the core OS choice and there is no way this project survives longer than the 30 grace period so no worries there.

What are you testing exactly? The addresses stored on the DNS service\daemon or the forwarding lookups? If it's just the response time for the stuff the service knows about then this setup is fine. If you are testing forward lookup speed, then you have to have dynamic list of destinations to look up; otherwise you're just testing the ARP caching.
Last edited on
Topic archived. No new replies allowed.