You have a server named Server1 that runs Windows Server 2012 R2. Server1 is located in
the perimeter network and has the DNS Server server role installed.
Server1 has a zone named contoso.com.
You App1y a security template to Server1.
After you App1y the template, users report that they can no longer resolve names from
contoso.com.
On Server1, you open DNS Manager as shown in the DNS exhibit. (Click the Exhibit button.)
On Server1, you open Windows Firewall with Advanced Security as shown in the Firewall
exhibit. (Click the Exhibit button.)
You need to ensure that users can resolve contoso.com names.
What should you do?
A.
From Windows Firewall with Advanced Security, disable the DNS (TCP, Incoming) rule
and the DNS (UDP, Incoming) rule.
B.
From DNS Manager, modify the Zone Transfers settings of the contoso.com zone.
C.
From DNS Manager, unsign the contoso.com zone.
D.
From DNS Manager, modify the Start of Authority (SOA) of the contoso.com zone.
E.
From Windows Firewall with Advanced Security, modify the profiles of the DNS (TCP,
Incoming) rule and the DNS (UDP, Incoming) rule.
Shoudn’t this be C?
Or can someone explain how E can be the correct answer. I can’t find any MS related article about changing firewall rules to allow DNSSec.
when you need change replication scope then should be unsign.
E because profile is private, I think it needs to be domain
Answer = E
http://technet.microsoft.com/en-us/library/jj878346.aspx
Can’t find a great reference but you can see in the graphic that only the Private profile is allowed, not All
My lab shows All, default configuration with DNS
In Predefined Rules, under Rules, select the checkboxes next to the following rules:
RPC (TCP, Incoming)
DNS (UDP, Incoming)
DNS (TCP, Incoming)
RPC Endpoint Mapper (TCP, Incoming)
Could it be the lack of RPC?
RPC is no option in provided answers, but I think you have to change the profile settings of the DNS rules…
As with most MS questions the answer can normally be deduced by logical thinking
1st read the question and understand the scenario
In this scenario I would assume that the DNS server is a secondary server as a Primary server in a perimeter network would be considered a security risk, with that in mind let us begin our process of logical thinking
A.
From Windows Firewall with Advanced Security, disable the DNS (TCP, Incoming) rule
and the DNS (UDP, Incoming) rule.
This would block all incoming DNS so NOT correct
B.
From DNS Manager, modify the Zone Transfers settings of the contoso.com zone.
As everything was working prior to the security update we can assume that Zone transfer is working so NOT correct
C.
From DNS Manager, unsign the contoso.com zone.
You cannot perform zone signing and unsigning or modify DNSSEC parameters of a zone on a secondary DNS server so NOT correct
D.
From DNS Manager, modify the Start of Authority (SOA) of the contoso.com zone.
As everything was working prior to the security update we can assume there is no issue with this so NOT correct
E.
From Windows Firewall with Advanced Security, modify the profiles of the DNS (TCP,
Incoming) rule and the DNS (UDP, Incoming) rule.
You could now be excused for thinking that as this is the only answer left available to us that it must be correct. IMHO this is also NOT correct.
see step 5 here https://www.microsoftpressstore.com/articles/article.aspx?p=2224362&seqNum=2
if users need to use the firewall rule when connected to their home networks, apply the rule to the Private profile
As this is a secondary DNS in a perimeter network we can assume that internal network clients will have no issue resolving DNS for contoso.com as the security policy has not been applied to the primary DNS server (as far as we have been informed)therefore it is external clients making incoming DNS requests to this perimeter DNS server that are reporting issues. As the incoming rule is configured for private as per the link above we can conclude that this is also NOT the answer
So what is the answer????
Kevin seems to have applied some logical thinking and I agree with him
What is RPC Endpoint mapper or Port Mapper?
When a Client communicates with a Server it performs and initial connection to Port 135 to communicate with the EPM “EndPoint Mapper”. The client has to bind to an interface first before it can call it’s procedures. Client has to perform 3 way RPC EPM handshake, once these handshakes are successful then the client will successfully bind. If the bind process was successful, it can send a request to the End Point Mapper, in which it includes the (universally unique identifier )UUID of the target interface.
I think that sometimes the purpose of these questions is to discourage robotic application of rote memory in the exam room but to encourage you to think your way through a scenario and research the answers for yourself if you are at all unsure. This way you will gain greater depth of knowledge and greater satisfaction in your IT career
PS You will also be able to show off at Board Meetings and get that well earned salary increase 🙂
ROTE MEMORY
Learning or memorization by repetition, often without an understanding of the reasoning or relationships involved in the material that is learned.
Good job Captain Condescension! All those words and you still didn’t give an answer that appears on the test!
Yes, I’m quite positive Microsoft’s intention is to present you a question with no correct answer to teach you the perils of rote memorization.
PS, You’ll be able to know people think you’re a pompous schmuck.
POMPOUS SCHMUCK
A twat like you.
James must have LOTS of friends who don’t talk about him behind his back!
747 days. That’s 2 years and 16 days and James is still a schmuck!
James L,
You are a loser.
Sincerely, Microsoft
James L: Your comment was quite possibly the most patronizing, condescending load of hubris I have ever read. GJ.
Better than how some people comment, by just saying E and not explaining why
Agree that it is E though
U sound like my mother….
I think ..
perimetral network = profile public
so your answer is?
Confirm E
Tried in Lab, if the profile is Private, the client in domain can’t resolve names. Setting up the rule for Domain or All profile, everything runs OK. This is valid for dns with or without DSNSSEC.
That’s why this forum is so great. Discuss the questions is a great way to gain knowledge.
And option E sounds fine to me. Because of the profile, that should contemplate ALL or ate least PUBLIC.
Why the fucking shit would anyone want their AD Integrated SIGNED ZONE TO BE ALLOWED FROM PUBLIC??!
As with any question on a Microsoft test, ask yourself, ‘How would Bill answer the question (Bill Gates)’. They all look like a bunch of fine answers, but E. is the longest. So, I will go with E. lol. Also ‘E’ is getting the most internet votes. I like to know why the answer is the answer as much as anyone. This appears to be one of those questions with only an answer but apparently conflicting information and therefore less useful to apply to the job.
I agree with all the guys who called James L a condescending schmuck and other names,he wrote an incredibly long and useless paragraph on the merits of true learning as apposed to memorizing,like memorizing isn’t what gets 99% of people through life,anyway,to James’s credit he did deconstruct any other option other than E,which leaves us with E as the only viable option,thanks a lot you asshole! (:
A: No, otherwise you block all the DNS traffic.
B: No, Perimeter DNS zone should not be AD-integrated, but secondary or stub zones. On “Zone Transfers settings” you specify a Secondary server. So this can be done on the internal DNS server.
C: No, signed or Unsigned doesn’t matter.
D: No, with Secondary zones and Stub zones, the “primary server” setting is greyed out, so can’t change this option.
E: Yes, the only option that can be true, so probably the NIC connected to your internal network has the Network profile “public” or “domain”. So the secuurity template must be modified the profile setting to “Private”.