DNSServerQueryResolutionPolicy Not Blocking

Question

question

agfreesafety3-6849 asked Mar 29, '22 GaryReynolds edited Apr 3, '22

DNSServerQueryResolutionPolicy Not Blocking

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)?

windows-server-powershell windows-dhcp-dns

capture.png (12.9 KiB)

· 3

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

agfreesafety3-6849 · Mar 29 at 05:01 PM

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.

0 ·

RichMatheisen-8856 · Mar 29 at 06:54 PM

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.

0 ·

agfreesafety3-6849 RichMatheisen-8856 · Mar 30 at 01:50 PM

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 :-(

0 ·

Answer 1 · 2022-03-31T21:26:28.807Z

GaryReynolds answered Mar 31, '22 GaryReynolds edited Apr 3, '22

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.

· 2

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

agfreesafety3-6849 · Apr 01 at 02:52 PM

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.

0 ·

GaryReynolds agfreesafety3-6849 · Apr 01 at 06:24 PM

Good to hear, please consider marking as answered.

Gary.

0 ·

Answer 2 · 2022-03-29T23:24:22.153Z

GaryReynolds answered Mar 29, '22 agfreesafety3-6849 commented Mar 31, '22

Hi @agfreesafety3-6849

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.

· 8

5 |1600 characters needed characters left characters exceeded

Attachments: Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

agfreesafety3-6849 · Mar 30 at 02:20 PM

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?

0 ·

capture.png (33.0 KiB)

capture.png (27.9 KiB)

GaryReynolds agfreesafety3-6849 · Mar 30 at 08:54 PM

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.

0 ·

agfreesafety3-6849 GaryReynolds · Mar 31 at 01:45 PM

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.

0 ·

agfreesafety3-6849 GaryReynolds · Mar 31 at 04:46 PM

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).

0 ·

capture.png (197.7 KiB)

Show more comments

question