Windows-itpro-docs: Provide better explanation for . (dot character) behavior in WDAG

[iadgovuser1]

It would be really useful to document the behavior of the . (dot character) explicitly on this page. For example, there is a difference between specifying:

• contoso.com - no dot
• .contoso.com - single dot
• ..contoso.com - two dots

The FAQ page is the only thing that even mentions .. (two dots) as an option. The Test Scenarios page gives no dot and single dot examples, but not much for explanation. The explanation probably best fits somewhere under the Network isolation settings heading.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 41a8c802-79ca-1593-c045-2ed150e9ce40
• Version Independent ID: 3dabd613-2eee-7c65-6f30-6746c8fb5bdf
• Content: Configure the Group Policy settings for Windows Defender Application Guard (Windows 10)
• Content Source: windows/security/threat-protection/windows-defender-application-guard/configure-wd-app-guard.md
• Product: w10
• Technology: windows
• GitHub Login: @Dansimp
• Microsoft Alias: dansimp

[mypil]

@officedocsbot assign @mypil

[mypil]

@iadgovuser1 - Thank you for submitting feedback.

I will get this issue over to the Win10 ITPro writing team for investigation.

Thank you for reporting and making the docs better. Much appreciated.

I made a note to request the team to update this when the work is complete.

[mypil]

@iadgovuser1 - From our understanding, the issue has been resolved but it may take a few days for the merged content to appear in the article. If you feel it hasn't been resolved, please re-open this issue.

Thank you for your contribution to make the docs better! Much appreciated!

[iadgovuser1]

@mypil

Looks like the change was that item 3 was added:

1. If you want to specify a complete domain, include a full domain name (for example "contoso.com") in the configuration.
2. You may optionally use "." as a previous wildcard character to automatically trust all subdomains (when there is more than one subdomain). Configuring ".constoso.com" will automatically trust "subdomain1.contoso.com", "subdomain2.contoso.com", etc.
3. To trust a subdomain, precede your domain with two dots, for example "..contoso.com".**

What's the difference between 2 and 3? For 2, it says one dot will trust all subdomains. Does that mean 3 does not trust all sub domains? This wording is still confusing to me. Does 3 mean just contoso.com is trusted while 2 means *.contoso.com is trusted? If that's the case, then 1 and 3 are the same behavior so that doesn't make sense either.

[mypil]

@ojrb - Please assist to answer the additional questions from @iadgovuser1.

Thank you.

[ojrb]

Hi @iadgovuser1 for clarification the option 2 can be used when you have more than one subdomain as explained on the example. potion 3 in an alternative when you have only one subdomain and want to trust on this !

[iadgovuser1]

@ojrb I asked a few people to take a look at the wording and we all agreed it is still confusing. I think the concept trying to be conveyed is how many "levels" of DNS hierarchy are trusted by the dot syntax.

For the example of (one dot) for 2: .contoso.com means www.contoso.com and web.contoso.com are trusted. Basically anything.contoso.com is trusted.

For the example of (two dots) for 3: ..contoso.com means all the above is trusted PLUS www2.www1.contoso.com, www3.www2.www1.contoso.com, etc, etc are trusted. Basically all subdomains, sub subdomains, sub sub subdomains, etc, are trusted.

If that is the idea that needs to be conveyed to the reader, then the current changes do not make that clear.

[mypil]

@iadgovuser1 - We value your efforts to clarify the docs and we encourage collaboration so we would like to get your kind assistance.

Could you please assist us by suggesting how this content could be edited to incorporate your feedback?

If you could suggest what the appropriate text and where it should be placed, I could assign @ojrb to create another Pull Request to get it added.

You also have the option to create a Pull Request to add in your suggestion and just link this issue so I can have the doc owner review and merge the content.

Thank you.

[ojrb]

@iadgovuser1 Please suggest us what's the appropriate text and where it should be placed, I can create another Pull Request to get it added.

[iadgovuser1]

@mypil @ojrb I will put a suggestion together tonight. Thanks.

[iadgovuser1]

By tonight I meant today...

[iadgovuser1]

@mypil @ojrb

I actually meant Saturday...

This example is meant to make the notation more clear.

| Value | # Dots to Left | Meaning |
| --- | --- | --- |
| contoso.com | 0 | Trust only the literal value of contoso.com. |
| www.contoso.com | 0 | Trust only the literal value of www.contoso.com. |
| .contoso.com | 1 | Trust only one level of the domain hierarchy that is to the left of the dot. Example matching sites include www.contoso.com, shop.contoso.com. |
| ..contoso.com | 2 | Trust all levels of the domain hierarchy that are to the left of the dot. Example matching sites include shop.contoso.com, us.shop.contoso.com, www.us.shop.contoso.com. |

Having a table in that part of the documentation wouldn't work well but I wasn't sure how else to display this.

[ojrb]

I will create another PR with the desired text !

[mypil]

@iadgovuser1 - The content has been updated to add the changes that you requested for based on this merged commit [2dc2a21]. Kindly check and let us know if your issue has been resolved. Thanks.

[jdgregson]

Am I missing something here? In my environment, .contoso.com trusts ANYTHING ending in contoso.com. That is, it trusts contoso.com, www.contoso.com, notcontoso.com, neverownedbycontoso.com, etc. The current explanation completely fails to illustrate this. Is this the intended behavior? Example video: https://jdgregson.com/research/wdag-whitelist.mp4

[mypil]

@jdgregson - Thank you for submitting feedback.

I think the best way forward is if you can contact support and open a service ticket for Windows 10 products so this can get resolved ASAP. Based on outcome, let me know if it is something that can be called out in the docs.

[jdgregson]

Thanks @mypil. WDAG in Enterprise-managed mode is an Enterprise-only feature, and I find it unlikely that the consumer oriented support personnel will have the knowledge or resources to provide an accurate answer. The only option I am finding to open a support request against WDAG requires a paid support subscription, which I do not have an am not interested in purchasing. Is there another way to get this request for clarification in front of the relevant team? I tweeted some teams, but that rarely helps: https://twitter.com/jdgregson/status/1166130156341063680

[iadgovuser1]

@jdgregson That is definitely not the behavior I expect dot to have and it isn't documented that way either. What release of Windows 10 are you seeing this behavior? I can bring this up with the product group this week.

[jdgregson]

@iadgovuser1 I am seeing this on Windows 10 Enterprise 1903 (OS build 18362.295). It may be important to note that I am configuring and enforcing WDAG in Enterprise-managed mode via Local Group Policy.

[jdgregson]

@iadgovuser1 I'd be curious to know if you're seeing this in your environment as well. As a simple test case, if you have ".google.com" in either the "Domains categorized as both work and personal" or "Enterprise resource domains hosted in the cloud" list, you should be able to go to http://notgoogle.com/ outside of WDAG (note that I have no affiliation with that site and do not endorse it).

I changed my list entry from ".google.com" to "..google.com" and now I am seeing the expected results: google.com and *.google.com are allowed, but notgoogle.com is not.

[jdgregson]

@iadgovuser1 Actually I spoke too soon, and it somehow gets worse. "..google.com" includes ONLY subdomains of google.com, but not the root domain. So to allow both "google.com" and "www.google.com" but not "notgoogle.com", you need to add both "google.com" and "..google.com" to the lists. This is very counter-intuitive, and now my lists must have two entries per site.

[iadgovuser1]

@jdgregson We can do some additional testing on our end. I believe we did recently come across the unexpected matching behavior you originally described, but we were experiencing other issues so didn't look into it more yet.

[iadgovuser1]

@jdgregson

So it seems like the rules are:

• never use 1 dot to the left because it can match anything within a domain string which is far too permissive
• to trust a specific domain/subdomain, and that domain/subdomain only, don't use any dots to the left
• to trust all sub domains, use 2 dots to the left. Note that to trust the main domain you will need an additional rule containing no dots to the left

[jdgregson]

@iadgovuser1 That accurately describes the behavior I am seeing. Not how I think it should work, but at least I know my implementation isn't broken.

@mypil Can we have someone on the WDAG team confirm whether this is the expected behavior or a bug? If it is expected then the documentation still needs to be updated and this issue should remain open.

[iadgovuser1]

@jdgregson Forgot to mention that the WDAG product group agreed the behavior needs better documentation.

[jdgregson]

@iadgovuser1 Well, I guess that means it is working as expected then. Maybe I'll submit a PR if I can find a better way to put it into words.

[iadgovuser1]

@jdgregson

Updated table below.

| Value | # Dots to Left | Meaning |
| --- | --- | --- |
| contoso.com | 0 | Trust only the literal value of contoso.com. |
| www.contoso.com | 0 | Trust only the literal value of www.contoso.com. |
| .contoso.com | 1 | Trust any domain that contains the text 'contoso.com'. Example matching sites include spearphishingcontoso.com, contoso.com, www.contoso.com. |
| ..contoso.com | 2 | Trust all levels of the domain hierarchy that are to the left of the dot. Example matching sites include shop.contoso.com, us.shop.contoso.com, www.us.shop.contoso.com, but NOT contoso.com itself. |

[iadgovuser1]

@mypil I also agree with @jdgregson (and the WDAG product group) that the documentation still needs to be made more clear here.

[mypil]

Reopening this issue as requested. Thank you @iadgovuser1 for sharing your inputs and also to @jdgregson for creating the PR.

We value and appreciate your feedback in helping to improve the content of our docs.

[mypil]

@jdgregson - The PR you created has been merged but it may take a few days for the merged content to appear in the article. We hope this resolves your issue.

Please do not hesitate to open a new issue if there is a specific area of the docs that we can improve or make better. Thank you.