@Jason_Stephenson said:
That’s why i need to block only based on the URL address that process x tries to resolve to IP
Your terminology is causing the confusion here. You want to conditionally block DNS.
I Apologize, yeah now that i am reading my question again i think i could’ve worded it better, i basically want intercept DNS & DNSsec packets and block certain URLs from getting resolved.
That’s why i need to block only based on the URL address that process x tries to resolve to IP
If he stated this in his OP then the vast majority of the ramblings in this thread could have been avoided . ergo - confusing.
is a suggested solution
Is the solution he needs and has asked for
you can go down the road to blocking DNS queries, and then discover that it doesn’t work in an increasingly large number of situations and therefore have to find another way to meet your requirements.
Will allow him to provide security for 90% of applications which are attempting to resolve IP’s while he builds up some understanding of DNS (and perhaps network protocols in general) before he moves onto the edge cases (other protocols). A standard iterative design approach.
@Jason_Stephenson said:
That’s why i need to block only based on the URL address that process x tries to resolve to IP
If he stated this in his OP then the vast majority of the ramblings in this thread could have been avoided . ergo - confusing.
That’s only one solution to this problem, that’s is why i didn’t say it in my OP. I basically want to block any process from connecting to URL x, whether via blocking DNS requests or any other methods. Hell, one might even inject into all processes and hook API calls to achieve this, its all up to you to decide which method is better.
Note that I already solved the problem for the case of simple DNS requests, via blocking the request. My main concern right now is DNSsec.
There is a lot of questionable wisdom on this thread. That’s true of most of the world of REST interfaces just as much as the world of those products designed to regulate them
it should be clear that there are many complex interactions between different levels of the classic OSI networking layers are happening here
in the beginning, the earth was void and without a forum for discussions of this kind - whoops wrong beginning
In the beginning the DNS cache will be empty and no extant TCP or UDP streams will exist. Then a request will be made to resolve a URL - there are many possible ways that this may be done by different UM programs, and several ways in which the OS might provide this. Ultimately, using one or more streams of UDP or TCP packets the ‘base URL’ will be resolved. That part will give you a basic IP address (IPv4 or IPv6 or theoretically an address in any other protocol at this level) but that doesn’t help you much. As others have pointed out, many different base URLs can resolve to the same IP address
The next part is to understand the other parts of the URL - the path and the query string.
next you need a state machine that understands the nuances of those requests
and then you need to do it all again, every time the semantics of the interface change - a frequent occurrence