On Fri, Jun 20, 2008 at 12:49 PM, Noel Chiappa <[EMAIL PROTECTED]> wrote: > It's been clear for a long time that use of IPvN addresses outside of a site > as part of configuration elsewhere, as opposed to using DNS names, introduces > brittleness into the system. > > So what I'm curious about is why people are doing that (using IPvN > addresses). Is it because there is some perceived robustness or security > issue with DNS? Or is it something where the fact that IPvN addresses and DNS > names aren't a 1:1 match is important? Or is it simply because it's 'easier' > to use IPvN addresses (no need to build in DNS resolution, etc)? (Or all of > the above, in differing cases?)
Hi Noel, In my own encounters, it has pretty much always been a question of, "What works?" Email reputation? Hundreds of ideas were thrown at the problem by thousands of people working independently. Several stuck because they were useful for identifying spam. Those included bayessian classification and source IP address use history. Nobody planned it that way and there was nothing dogmatic about it. It was just an organic response to, "What the heck can we do to get an edge on the spammers?" IPSec VPNs? The most widely deployed product is the Cisco PIX/ASA. You configure the cryptomaps with IP addresses and netmasks and if they don't match on both sides, it doesn't work. It simply isn't possible to configure them with something other than bare addresses. Is it even practical to build an IPSec VPN appliance that configures and reconfigures tunnels dynamically based on hostnames? Hostnames work fine for SSL VPNs, but IPSec's function is so arcane that I'm not sure it's possible to work with it in any other way besides bare IP addresses. I don't think perception of security plays a major role any more. It's still waiting in the wings, but the major concerns at this point are all practical: we have to operate in a manner compatible with what that other guy is doing or our stuff won't work. The bottom line is that our stuff has to work. > > Placing your customer web servers behind a NAT box ... > > They can't avoid that problem up front with CNAMEs to your DNS because > > they often desire the same name that holds the NS and SOA records to > > reach the web site. > > Another place where the architecture has too few namespaces. > "somecompany.com" is overloaded as i) the website's secondary DNS name (after > www.somecompany.com), and ii) the NS/SOA name... (at least, if I understood > your point correctly). The point I was making is that DNS has no concept of, "this name has the same IP address as that name over there." Instead it has CNAMEs which mean, "the answer to this record is the same as the answer to that record over there." The difference is that no name which is a delegation component can reference another name's IP address because the delegation components have SOA and NS records which are unique to them. Www.mycompany.com can have a CNAME but Mycompany.com can't. Since everybody wants http://mycompany.com/ to go to their web site, this DNS CNAMEs don't ease address renumbering. Regards, Bill -- William D. Herrin ................ [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
