Les Mikesell wrote:
bruce wrote:As I understand the issue. The issue is one of being able to poison the DNS app on the DNS server. There's not really much the casual user can do, aside from switching to another DNS/IP address that's safe. But the rub is, do youreally know if the DNS/IP you're switching to is safe!If you are really paranoid (or about to do large transactions on what you hope is your banking site), you could do a 'whois' lookup for the target domain to find their own name servers and send a query directly there for the target site.The best approach, would probably be a system to allow you to poll a few DNS servers, and to take the returned ip address that comes back from the most of them as the "correct" ip address!! but this isn't implemented anywhere asfar as i know....dig @dns_server target_namewill send a query to a specified DNS resolver. Most public-facing servers will only resolve the names of their own zones, especially now. I think the current vulnerability only involves cached addresses for which the server is not primary or secondary.
BUT, here is the really BAD news:a) 99.9% of the internet is really a cached service. The only true DNS entries are on the name servers that originated the DNS entry. This is why when you put up a new domain they suggest waiting about 3-4 days for the internet to propagate the DNS names. The information trickles down the DNS servers until everyone has the corrected information or update.
b) If the DNS is corrupted you can't rely on the DNS resolver to be pointing to the correct IP.!! You could be digging on the phishing site and they would be reporting false and bad information to you so they can scam you of your passwords and/or money.
James Kosin
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
