Access-list based on domain name

Only by the IP address, not hostname.

Everything resolves to IP anyways for transfer, so the answer is yes. Just do a nslookup on the blackberry.net servers or find what the source IPs are of what is hitting you now, and block it off.

So by IP address only? I really do not see where my post was wrong. The PIX/ASA can only block sites by IP address not by hostname which is what the OP's question assked.

So what if he had two different domains, but wanted to block access from one and allow from the other but they both resolve to the same IP address? As Chad said, you can't block on domain, only IP.

Chris.

You need to consider that for many protocols, the router won't even know what host *name* the local computer wants to connect to on the internet.

The local computer will resolve "chocolate.blackberry.net" to some IP address, and then request a connection to that IP address with a specified port. The router will see those packets and may act on them, but it only sees the IP and port numbers.

If blackberry uses its own proprietary protocol using its own port number, you might have better chances of blocking all requests to that port number , no matter what the IP address of the destination is.

Yet another example of the inferiority of the PIX / ASA platform - it really is about time Cisco supported this....

James

James wrote in news:1185241908.130444.259640 @e9g2000prf.googlegroups.com:

Access-list by domain name have (IMHO) no sense: - For each new IP address requesting access to your network you will have to do a reverse name lookup, this can take several seconds!!! - Suppose you want to allow pinkberry.net to access your network, I can set the reverse DNS for an IP address I own to 'evilhacker.pinkberry.net'. I just need to own the IP address and have the control on its reverse DNS. To avoid such a trick you will need to do a DNS query to check if evilhacker.pinkberry.net has the good IP ==> 2 IP DNS lookups

Usually access control by domain name are for HTTP only and are based on the HTTP header 'host:'. That is ISO layer 7 and not ISO layer 3/4.

Just my 0.02 EUR.

Even if you did it that way you'd have to cache the DNS lookups for the TTL of the record, which would reduce the problem you describe but leave the firewall open to a DOS attack if the cache got too large or the DNS lookup failed. But you probably wouldn't do it that way ...

... you'd look up the addresses when the ACL was compiled, avoiding that particular problem but generating a new one that you'd have to check the TTLs of the DNS records, refetch them when they expired and if necessary recompile the ACL when anything changed. Big problems when DNS lookups fail (what do you do if you can't match one name in the list?) and could also give DOS problems. Also when an address changed the ACL would lag by up to the TTL (though that might be better than most humans can manage!), and there'd be real problems with name based servers hosted on the same address.

Which may be what the original poster was thinking of, or maybe he just hadn't thought it through. I'd be interested to know what he was thinking the PIX/ASA was inferior to.

My 2p, approx 0.03 EUR or 0.04 USD.

Sam

In my opinion the PIX / ASA is inferior to Netscreen, Checkpoint, Watchguard, Fortinet......

The Netscreen uses a combination of DNS and looking at the request header - on a Netscreen box I can have a rule which denies access to companyx.com. This rulle will block access to

and ftp.companyx.com. The unit Caches responses - you manually set how often it refreshes. You don't need to worry about the Cache becoming too large or DOS attacks because it only performs lookup's on host's you have specified in the Policy.

"The request header"? That implies a protocol that has such a thing that the box can read - HTTP has, FTP hasn't, HTTPS has but intermediate boxes can't read it. I'm not saying that's not a useful feature (and I'm not a Cisco advocate, just a sometimes satisfied Cisco user) just that it must be of limited use.

So it can't track a rapidly changing address and may have trouble with some of the large hosting sites which are dynamic and selective with their DNS responses, and may give the Netscreen a different set of address than they give other clients.

It may be that Netscreen have this sorted or that it's only applicable in certain limited circumstances - I'm having trouble see how you could create a universal solution (just as filtering by IP address isn't a universal solution).

Sam