Episode 63 – DNS Mess

Podcast August 24th, 2008

Recorded: August 19, 2008
Your Host: Keith Albright and Steven Murawski
Show Length: 52:03

In this episode, Steve and I interview Steve Friedl and discuss his white paper on the DNS vulnerability. Steve explains how it works and how you can protect yourself.

Thanks for listening and we hope you enjoy.

Links mentioned in this show:

 Read the full show notes here.

Website Picks:

Keith – SharkBait and SharkTank

Listen Now:

Download Here



Comments

  1. 1
    Brad
    August 26th, 2008 at 12:03 pm

    I have been using Live Mesh for 2 months now, and for the most part I’m very happy with it. I find that the RDC reaction time is very slow compared to LogMeIn, but I know it is still a CTP and things will get better with updates and feed back. The one thing that does frustrate me with Live Mesh is that you have to go through a Windows Live log on page to connect. Usually this is not an issue however working for a school district as my day job we have to block this site because of our policies on messaging programs. It just wish there was an alternative for the logon page, since if we allow access to Live Mesh we would also be allowing access to Web Messengers.

  2. 2
    Martin
    September 3rd, 2008 at 1:46 pm

    Great podcast with excellent input on the DNS vulnerability issue. One question I do have is why are we concerned with firewall vendors such as SonicWall and their (probable) inability to adjust their OS’s to allow for greater port scopes when the real issue lies on Public DNS servers; ISP’s or any other open DNS servers – won’t those servers be open anyway and probably use appliances from larger manufacturers?

  3. 3
    Steve
    September 3rd, 2008 at 9:25 pm

    Martin – The problem with the firewall comes in to play when you are running your own DNS server that local clients use for name resolution. When a client on your local network attempts to resolve a name, it queries your local DNS server, which will check with the appropriate root DNS server, which will forward it to the DNS servers registered for the target domain. Since your local DNS server is querying out from inside your network, it will send the queries from random ports (if it is patched), but if the firewall is using PAT (port address translation) it can use a different series of ports for the queries, often in close range and in a predictable pattern, making them more prone to falling for the spoofing attack.

  4. 4
    Martin
    September 5th, 2008 at 7:27 am

    Ok makes sense, thank you for the feedback. Now, if an internal domain DNS server hosts zones for the office domain but uses Forwarders (ISP DNS servers) do I have to be concerned if my ISP DNS servers check out OK using the dns tests? I’m guessing our internal DNS server can still be poisoned between the office isp dns.

  5. 5
    Steve
    September 5th, 2008 at 11:16 am

    Martin –
    If your ISP’s DNS is patched, you are probably ok (as much as if you were using your own patched dns server). I say probably because the patches only increase the difficulty of the attack, it does not prevent it fully.

  6. 6
    Saurabh
    October 14th, 2008 at 6:50 am

    Hi ,

    I have configured the DNS and it is well resolving on my side .but on the client side it is not able to resolve by public ip .i have checked the natted entry on the firewall also .what might be the problem .plz suggest some solution.

  7. 7
    Steve
    October 15th, 2008 at 11:52 am

    Saurabh,

    I’d like to clarify a couple of things… is the DNS Server you are referring to handling your public DNS records (acting as the nameservers for your domain) or is it a local caching nameserver for your internal clients?

    If you are having a problem with external clients being able to resolve DNS entries pointing towards your IPs, you might want to check with your domain registrar and make sure that your nameserver is authoritative for your domain.

    I’ll email you also.

Trackbacks

  1. Sky Blog: phanleson’s blog » Steve Friedl’s Unixwiz.net Tech Tips An Illustrated Guide to the Kaminsky DNS Vulnerability

Leave a Comment

You must be logged in to post a comment.

blank