Introduction To DNS and DNSSEC

This video provides an introduction to DNS, covering the organization and delegation of the DNS namespace, the DNS resolution process including how DNSSEC validation is performed, wrapping up with discussion of some additional DNS security considerations.

[@ianokay]

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.

[@HeinzBigler]

Thanks, the best I found so far.

[@karamjeetpadam4719]

excellent explanation of the subject Tim. Good work and Good job of sharing your deep insights and knowledge.

[@AaaRrrLllUS]

Thank you, very good explanation!

[@mrobjectoriented]

To the point explanation. Thank you!

[@aligzaidi]

Very detailed intro. A+ Thanks.

[@cyberguide_in]

Great explanation! Thank you

[@simerpreetanand516]

Thank You!

[@SkaNarrator]

Great video!

[@rohitchaudhary179]

Very complex concept easily explained .. :) thanks !!

[@KashiPrayag]

very nice

[@1UniverseGames]

How do you design those diagram, which software do u use for this

[@peanorg]

Even if you have a hidden master it should be mentioned in the SOA record?

[@trooney851]

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.

[@fbifido2]

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

[@trooney851]

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.