DNSServerQueryResolutionPolicy Not Blocking

Question

DNSServerQueryResolutionPolicy Not Blocking

agfreesafety3 41

This is somewhat related to a similar issue I posted about a few days ago here.

I have DENY policies in place for two subdomains and I'm able to get them to ping successfully with no issues.

I had these set to IGNORE before, but due to me still being able to ping between resources in both prod and qa, I removed those two policies and recreated them using DENY instead

I looked in the dns debug log and as expected, there are no "refused" messages anywhere in it.

How do I go about troubleshooting this, when, from what I see, the subnets were defined correctly, and the syntax of the commands are correct (at least I think they are)?

agfreesafety3 41 Reputation points

2022-03-29T17:01:15.667+00:00

There are two DNS hosts, but from what I can see, they're both configured the same, DNS policy-wise. The subnet definitions/aliases are the same between the two DNS hosts as well.
Rich Matheisen 47,901 Reputation points

2022-03-29T18:54:40.033+00:00

Did you clear the client DNS resolver cache before you tested? For good measure, I'd clear the DNS server's cache, too.

Are you doing the testing using a FQDN? If you're using only the hostname and depending on the client to add a domain name you may be using NetBIOS to resolve the name.
agfreesafety3 41 Reputation points

2022-03-30T13:50:49.487+00:00

The hosts I'm testing this out on are Linux, I'm told they don't have local DNS caches like Windows hosts do. And yes sir, I'm using FQDN when I do the Nslookups now, and I'm getting the same results :-(

Accepted answer

1 additional answer

Your answer

agfreesafety3 41 Reputation points

2022-03-29T17:01:15.667+00:00

There are two DNS hosts, but from what I can see, they're both configured the same, DNS policy-wise. The subnet definitions/aliases are the same between the two DNS hosts as well.
Rich Matheisen 47,901 Reputation points

2022-03-29T18:54:40.033+00:00

Did you clear the client DNS resolver cache before you tested? For good measure, I'd clear the DNS server's cache, too.

Are you doing the testing using a FQDN? If you're using only the hostname and depending on the client to add a domain name you may be using NetBIOS to resolve the name.
agfreesafety3 41 Reputation points

2022-03-30T13:50:49.487+00:00

The hosts I'm testing this out on are Linux, I'm told they don't have local DNS caches like Windows hosts do. And yes sir, I'm using FQDN when I do the Nslookups now, and I'm getting the same results :-(

Answer 1

Ok, now I understand why it's not working.

The Add-DnsServerQueryPolicy command is used to configure a set of matching rules or criteria, these criteria are then checked against the incoming DNS queries, if all the criteria match, then the action is applied.

For your policy, I think you are looking for this, please correct if this is wrong:

Machines are in the newdev ip address range, that try to resolve *.dev.abc.internal block the query

These are the commands that you need to enter:

 Add-DnsServerClientSubnet -name NewDev -ipv4subnet 192.168.1.0/24

This defines the IP address range of the machines that you want to block from accessing the dev.abc.internal domain. As I mentioned in your other post, there is no method to check if a machine is registered to a specific DNS domain, IP address is the only option to filter at a machine level.

 Add-DnsServerQueryResolutionPolicy -name prodblock -action deny -fqdn "EQ,*.dev.*abc*.internal" -ClientSubnet "EQ,NewDev"

This policy will check any incoming query that are for the dev.abc.internal domain, including any entry or subdomains, and the client machine has an IP address in the NewDev IP address range then the query will be blocked. If the FDQN parameter doesn't include a wildcard, only the specified FQDN will be blocked. So to block all entries in a domain, the FQDN parameter would be *.dev.abc.internal.

The configuration of the DNS policies is very clunky and some sort of verification cmdlet would be useful. I have thought about creating a tool to do this, as my limited playing with the DNS policy has highlighted how painful this is.

Gary.

agfreesafety3 41 Reputation points

2022-04-01T14:52:15.57+00:00

Man oh man! Come to find out, these have been working the whole time, it just works the opposite way/direction than how I interpreted it. So in my most recent screenshot, i labelled it "devblockqa" , it should be named "qablockdev". I'm all set. Thanks for your time man. I REALLY appreciate you.
Gary Reynolds 9,621 Reputation points

2022-04-01T18:24:44.087+00:00

Good to hear, please consider marking as answered.

Gary.

Answer 2

Gary Reynolds 9,621

Hi @agfreesafety3

Based on the commands you have entered the policy will only apply to queries for dns zones called 'prodxxxx' or 'qa'. This parameter should be the full domain name, not just the subdomain. It should be prod.abc.internal or qa.abc.internal based on previously provided information.

When using the ping command it can use either dns or local name resolution. When you run the ping make sure the name returned shows a fqdn, otherwise it's using local name resolution and not the dns server. It's better to use nslookup to check that the policies are working correctly.

Gary.

agfreesafety3 41 Reputation points

2022-03-30T14:20:25.167+00:00

I removed and readded the policy for qa to deny prod, this time using the fqdn :

Until I get this working, i decided to focus on just one policy, as it's getting confusing trying to manually enter all of these changes accurately on both DNS hosts. The policy I'm focusing on for now is getting qa to DENY queries from either of the subnets we are categorizing as prod, which is why there's to policies shown above for qa to block prod queries.

So anyways, after re-entering the policies, I ran a nslookup from the Linux machine that's in prod to the qa machine, and it responded with results from the nslookup I ran against the qa machine from my prod machine. Did I do something wrong?
Gary Reynolds 9,621 Reputation points

2022-03-30T20:54:37.637+00:00

Hi,

The commands look ok and should block the the selected zones from the qa subnet, however, I would check the other policies you have set as the two policies have a processing order of 9 & 10, if there is a policy higher in the order which allows, that will take precedence over these policies.

I would use Get-DnsServerQueryResolutionPolicy to check the details of the other policies that have been defined.

Also to simplify the configuration of the policies, you can use the -computername option to specified the server name, so you can configure all the other servers from one server.

Gary.
agfreesafety3 41 Reputation points

2022-03-31T13:45:37.313+00:00

I feel defeated! :-) I removed all of the policies (on both DNS hosts) so that there's just the one for dev blocking qa, again on both DNS hosts, and I'm still able to nslookup and ping the resource in dev from my qa linux machine.
here's a link to an image of my setup on the dns hosts

Any more ideas? thanks for your help; you've been my only help with this project. None of my colleagues at work have been of any help.
agfreesafety3 41 Reputation points

2022-03-31T16:46:28.257+00:00

I'm still able to resolve the IP, even after making the capitalizations identical on both DNS hosts; both for the query definition as well as the capitalization of the subnet name. The only DNS host that "should" matter is the top DNS host now, as we modified the resolv.conf on the qa Linux resource I'm using for this test to point only to the main DNS host (the top one).
agfreesafety3 41 Reputation points

2022-03-31T17:49:15.807+00:00

...by the way, there's still other subnets defined, however the only two in use right now are newDEV (which is what I'm using as "dev", sorry for that confusion), and the only other one in-use right now is qa. I removed all other policies from both dns hosts, except for the one I configured with the intention of having DEV (aka newDEV) block queries from qa.
Gary Reynolds 9,621 Reputation points

2022-03-31T17:53:07.933+00:00

Hang in there, you are pretty close.

In your fqdn parameter you have a space after the eq, try removing that. Also if you want to block all the entries in the qa zone, try adding a wildcard to the fqdn i.e "eq,*.qa.abc.internal"

Gary.
agfreesafety3 41 Reputation points

2022-03-31T18:26:36.853+00:00

I made your requested modifications and it's still resolving the IP.

Does it make a difference if the subnet name I defined (newdev) isn't the same name of the subdomain under the {redacted}.internal in DNS manager? In DNS Manager, the name of the subdomain under {redacted}.internal in DNS manager is just simply dev.

Just thought I'd mention that in case that might make a difference.
agfreesafety3 41 Reputation points

2022-03-31T18:33:33.683+00:00

If there was something entered incorrectly, it would be nice for Powershell to tell me. I don't know what else to do to troubleshoot what's going on. Might the issue be something else within the infrastructure besides the powershell script?

Share via

DNSServerQueryResolutionPolicy Not Blocking

1 additional answer

Your answer