A lot of name resolver have a kind of suffix lists (or search list) to lookup when trying to resolve a non-FQDN hostname. This use is quite common in internal (e.g. in large company) networks to ease the typing of people. Like that people can type intranet in their favourite browser instead of typing the FQDN like intranet.mycompany.internal. In theory, this looks nice and lazy users are quite happy. In practise, this is a nightmare… One the common example, company have a global suffix configured on all internal desktop computers like :
.dyn.mycompany.internal
.mycompany.internal
Just imagine, a simple misconfigured dynamic name client named "intranet". In such order, the intranet.dyn.mycompany.internal will be resolved before intranet.mycompany.internal. The easy solution will be to change the order of the search list to avoid the described scenario. Yes this could solve a part of the issue as long as the user is not setting up is own suffix list. The suffix can be also received dynamically if the DHCP server is supporting the RFC3397 as an extension (especially look at section 4. Security Consideration) . That adds some complexity in the potential scenario of the name resolution and that's not good on a security perspective. Just have a look at the flowchart made in the name resolution documentation from Microsoft. You have a variety of case as long as the name resolution software is behaving as expected. The situation is somehow the same with the search list in the Unix-like world. Do we still need suffix search list for name resolution ? does it help or is this adding too much potential issues (from security to simple network debugging) ? If someone is asking me about it, just remove all search list (static or dynamic) and inform users to always use FQDN.
Tags : name_resolution dns security fqdn system_administration
![[FSF
Associate Member]](http://www.foo.be/fsfbutton-adulau.png){kind=small}
