--On Saturday, November 13, 2004 2:56 +0100 Daniel Roesen <[EMAIL PROTECTED]> wrote:
On Fri, Nov 12, 2004 at 05:06:17PM -0800, Owen DeLong wrote:> OK, but this doesn't have any effect on your "Listen", > "NameVirtualHost" and "<VirtualHost>" statements of your httpd.conf, > "ListenAddress" in sshd.conf, "Bind" in proftpd.conf, "*-source" and > "listen-on*" in named.conf, [...] > True. However, in all of the cases above except named.conf, names are a perfectly valid substitute for the IP address.
No. Those configs are read at boot-time. Now think about a power outage recovery. Server comes up but cannot reach DNS when services are starting up. Boom, your server's services bail out and are dead in the water. To prevent this, you might fill your /etc/hosts with the own FQDN-to-IP mappings, but this again has the problem of being pretty static.
Or... Recognizing that you have a dependency on DNS, you include S10WaitForDns in your rc3.d and don't continue the bootstrap until DNS is reachable. Of course, if you're all _THAT_ worried about it, you make your host a secondary for the domains it needs to know about and have it run a caching resolver that is authoritative for the local domains which only binds to the localhost port, so, no problem and not static. Then, you just need to start BIND before you start those services.
> Not to forget all the IP address based ACLs. > I suspect that eventually, we will discover that ADDRESS-based ACLs simply do not scale to a V6 world, and, you will see support for other strategies, such as host-name based ACLs.
Layer 3 doesn't know host names. Nor does layer 4. Applications do. Security requirements do often mandate working access control even when DNS doesn't work or is compromised.
Security requirements are that you not permit packets that should not be when DNS is not working. Nothing says the router cannot run a resolver pass when parsing the ACL or when told to refresh the ACL to translate the configured names into IP addresses. Nothing precludes a periodic automatic refresh.
Hope this helps show that these problems can be mitigated in more scalable ways.
Owen
-- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery.
pgp0iNqQ9HxVE.pgp
Description: PGP signature
