This was absolutely amazing, thanks. The additional information at the very end was stellar and an amazing surprise bonus. I'm not even in this field directly, but it's awesome to be given all the context by a clear, very experienced, expert.
Sorry for my tardy response, but it should not be mentioned in the SOA, or it will no longer be hidden! Another slave, which is equally authoritative for the zone data, can be listed as the zone master instead. By not publishing who the master is, you're making it a bit harder for an attacker from identifying then targeting the master in order to manipulate zone data or otherwise wreak havoc.
@9:22 why couldn't the root server, ask the TLD server, whom then ask the example server for this info, and not have the recursive server do this back-and-forth thing?
You see some server has to "take responsibility" for finding the ultimate answer. If the root server asked the TLD server, it would need to manage the state of the query, await an answer or timeout; likewise the TLD would do the same to its child and so on...tying up resources on servers down the domain tree. So you can imagine creating such a multi-layered query process would consume most of the resources of these already very busy servers and would not scale. So the recursive server is "responsible" for finding the answer and must manage the state of the query to find an answer or timeout. This allows the root, TLDs and other authoritative servers to simply receive queries and provide answers.
This was absolutely amazing, thanks. The additional information at the very end was stellar and an amazing surprise bonus. I'm not even in this field directly, but it's awesome to be given all the context by a clear, very experienced, expert.
excellent explanation of the subject Tim. Good work and Good job of sharing your deep insights and knowledge.
Thanks, the best I found so far.
To the point explanation. Thank you!
Very detailed intro. A+ Thanks.
Very complex concept easily explained .. :) thanks !!
Thank you, very good explanation!
Great explanation! Thank you
very nice
Even if you have a hidden master it should be mentioned in the SOA record?
Sorry for my tardy response, but it should not be mentioned in the SOA, or it will no longer be hidden! Another slave, which is equally authoritative for the zone data, can be listed as the zone master instead. By not publishing who the master is, you're making it a bit harder for an attacker from identifying then targeting the master in order to manipulate zone data or otherwise wreak havoc.
Great video!
How do you design those diagram, which software do u use for this
Thank You!
@9:22 why couldn't the root server, ask the TLD server, whom then ask the example server for this info, and not have the recursive server do this back-and-forth thing?
You see some server has to "take responsibility" for finding the ultimate answer. If the root server asked the TLD server, it would need to manage the state of the query, await an answer or timeout; likewise the TLD would do the same to its child and so on...tying up resources on servers down the domain tree. So you can imagine creating such a multi-layered query process would consume most of the resources of these already very busy servers and would not scale. So the recursive server is "responsible" for finding the answer and must manage the state of the query to find an answer or timeout. This allows the root, TLDs and other authoritative servers to simply receive queries and provide answers.