Opening with DNS, HTTPS, TCP, etc. could end up being a complete waste of time depending on what signals your looking for, what you're really asking, and your background. I'm curious how my responses would be interpreted by you as someone who's asked questions like this before?
Like, my goal isn't to see how much of a spiel you've rehearsed for a finite set of possible interview questions.
That sort of exercise constitutes a useless hazing ritual that selects for people with low anxiety at the moment, not aptitude with the relevant technologies for the job.
I'm going to keep pushing the conversation along until you've either hit the depth of your knowledge and say "I'm not sure", or we need to move onto other questions. If we hit your depth early but we're headed into an interesting direction, I might ask, "How would you build [protocol or feature you're not sure about]?" This potentially gives useful data in how you, as a candidate, approach abstract problems.
But I should also note: I'm an introvert. I'm shy. I get nervous easily in social situations. I'm not the best interviewer, and I don't believe the processes I learned from my employers are necessarily the right way to hire technical expertise. I would rather replace the interview with timeboxed work-sample tests. But I don't call those shots.
With the first type of response, when you follow up with how do we know where the webserver is, there is usually uncertainty. The whole point of open ended questions is to understand where your technical understanding is, not to hit a bunch of keywords on the way. This type of question though is way outside the norm though, I think it is a misunderstanding on the interviewee's part if they think this is an exercise in saying specific terms. I can see how its potentially more frustrating- there is no pass/fail, just how well did you do on a scale that is a bit subjective.
If you want to spend 20 minutes talking about DNS, I'm going to ask a lot of follow-up questions throughout the process, not fail you for not meeting a rubric or magic list of buzzwords. My goal will be to see how deep your knowledge on a particular piece of technology is, especially for a security role.
The problem here isn't the question; the question is a tool. The problem is that the interviewer isn't using the tool appropriately.
(Note: I don't choose these questions, the team I work for did. I follow a script, and it includes questions like this. But the script also contains a reminder for how to use the damn question.)