back to article World's biggest ISPs drag feet on critical DNS patch

More than two weeks after security researchers warned of a critical defect in the net's address lookup system, some of the world's biggest internet service providers - including AT&T, Time Warner and Bell Canada - have yet to install a patch inoculating their subscribers against attacks, according to an informal survey of …

COMMENTS

This topic is closed for new posts.
  1. Anonymous Coward
    Coat

    All your DNS

    are belong to us.

    It can't be that bad, can it?

    Tweed with the patches on the elbows, thanks.

  2. Michael Greenhill

    Suprise suprise

    At least one of Telstra's name servers are vulnerable.

    203.215.3.43

  3. Anonymous Coward
    Pirate

    Virgin Media status

    I wonder if Virgin Media would mind me injecting my own subdomain onto their DNS to replace the boring ubr.locale.blueyonder.co.uk format? :)

  4. Alan W. Rateliff, II
    Paris Hilton

    AT&T Wireless' DNS

    According to the site, AT&T Wireless is susceptible when using the isp.cingular APN. Not sure about the wap.cingular APN, but I would venture to guess the condition is the same. DNS server assigned is 209.183.35.2.

    Paris, possibly susceptible, but the firewall or nat router may be interfering with her port selection policy.

  5. Chris Gray
    Thumb Up

    Canada's Shaw Cable OK

    Shaw Cable in Canada seems OK:

    Your name server, at 64.59.184.15, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.Requests seen for b14aed6a1cd3.toorrr.com:

    64.59.184.15:21877 TXID=14695

    64.59.184.15:23901 TXID=9436

    64.59.184.15:30578 TXID=50420

    64.59.184.15:20735 TXID=39373

    64.59.184.15:9712 TXID=46561

  6. Silo Spen
    Thumb Down

    Insecure DNS

    Over here in SK, my ISP is wide open.

    59.0.159.86

    Korean Telecom/KORNET

  7. lord_farquaad
    Thumb Up

    Orange France

    I am on holydays in France and connected to Orange and it seems safe ...

  8. Jack the Bat
    Thumb Down

    PCCW in Hong Kong remains vulnerable

    Your name server, at 218.102.23.228, appears vulnerable to DNS Cache Poisoning.

    I sent this by email to PCCW execs weeks ago, but no response, and no change.

  9. Belxjander Serechai

    Add OCN Japan to the blackened ISPs listing...

    DNS needs to be "patched" here too

    but I can bet NTT is on to it...

  10. Pete Spicer
    Thumb Up

    Tiscali

    I know Tiscali has been something of a target for bad press before but their servers are all good according to the Check My DNS widget.

  11. Adrian Bridgett

    Time to patch

    The fact that some organisations take a month to roll out an urgent security patch isn't an excuse. It's just another problem that those organisations needs to sort out.

    Taking time to test thoroughly is good, but there needs to be a sliding scale of risk due to not testing and risk due to not patching.

  12. mad clarinet
    Coat

    50/50 result

    I checked my Virginmedia DNS last night and it reported okay.

    I tested the one at work this morning and its not patched (but I'm not surprised at that result).

    Okay... mine's the one with the CV's in the pockets....

  13. Matt Roxburgh

    TalkTalk & AOL were patched a while back ..

    You list OPAL as bein unpatched but AOL & TalkTalk were patched a while back and pass the "Check Your DNS" test.

  14. Anonymous Coward
    Dead Vulture

    KORNET!

    Silo - Good luck to you mate, knowing KORNET, the DNS might be patched some time in the next 10 years (along with the rest of the korean infrastructure).

  15. Craig

    Zen

    A big well done to Zen for getting theirs done so quickly. I ran the test the first time it was announced and it came up with the "safe" notice.

    Another reason to be happy wtih moving from BT in my own personal "phorm" protest :)

  16. Adam Richardson
    Thumb Up

    Eclipse ISP is OK :)

    Top marks to my ISP, Eclipse. The test shows they pass :)

  17. Neil

    @lord_farquaad

    Stop reading the reg and get back to your holidays, Geek!

  18. Bronek Kozicki Silver badge

    In SSL we trust

    It's high time users should learn to verify SSL certificates of sites of any importance to them. This also nullifies most dangerous effects of DNS poisoning - which is not a new attack type, BTW.

  19. John Robson Silver badge

    Don't bother with open DNS on Virgin

    IIRC they snat you away to their own servers anyway, we need dns over ssl...

  20. Christoph Silver badge

    Merula passes OK

    Err - wot the title says

  21. 2Fast
    Thumb Up

    Server patch

    Did wonders for me, updated the linux servers bind daemon and it killed everything i really enjoyed manually rebuilding what the patch had done...

    JOY.

    6 months to bring out this patch jeez...... fair played to the guy who found it though and kept it hush hush instead of taking advantage of the problem.

  22. Dave Harris

    TM Net in Malaysia apparently affected

    Your name server, at 203.121.65.39, appears vulnerable to DNS Cache Poisoning.

  23. Jamie Mitchell

    3 in UK are vulnerable

    195.27.150.140 used by 3 is vulnerable... and if you are using their wireless broadband modem you cant hardcode DNS server addresses

  24. Anonymous Coward
    Anonymous Coward

    MegaVista... near Alicante, Spain

    small ISP... got WiMax air interface... works tops... but urgh! not when their DNS's are vulnerable... 213.172.33.34 and 213.172.33.35... sent their admins an email this morning...

    Qu: large ISP or small ISP more responsive to something like this?

  25. Anonymous Coward
    Thumb Up

    o2 Broadband seems OK

    Your name server, at 87.194.0.66, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.

    Requests seen for 0fdf9cf5fbac.toorrr.com:

    87.194.0.66:23676 TXID=55910

    87.194.0.66:45831 TXID=52634

    87.194.0.66:22724 TXID=59957

    87.194.0.66:35609 TXID=51197

    87.194.0.66:5856 TXID=45189

  26. Anonymous Coward
    Unhappy

    Well done work ... gotta check Be* when I get home

    Your name server, at 213.130.128.31, appears vulnerable to DNS Cache Poisoning.

    g0-1-41.ac3-u1-sal-uk.as15444.net -> netdnscache01.eng.net

  27. Anonymous Coward
    Heart

    Virgin Media DNS

    Firstly, Virgin started patching for this bug a *month* before the public announcement. We're really friendly with our DNS supplier :-)

    Secondly, OpenDNS works fine on Virgin Media, we don't "snat you away" (whatever that means) in any way. I suggest you update your memory with a fact or two :-)

  28. Stuart Halliday
    Happy

    Virgin Media and Pipex are patched

    I can confirm that VM and Pipex seem ok.

  29. Steven Foster

    Bethere?

    Have Bethere patched this yet?

  30. spam
    Thumb Down

    UK Online are vulnerable

    UK Online's DNS servers are vulnerable. They're owned by Sky but I don't know if they use the same servers as Skybroadband.

  31. Tom Silver badge

    @AC + Steven Foster

    Be are in the clear (unsurprising, since they are the same as O2).

  32. Paul Stephenson
    Happy

    Karoo OK

    Karoo's 'opt-out' DNS servers check out OK. Not sure about the default one's though.

  33. Anonymous Coward
    Anonymous Coward

    Griffin Internet - patched

    Griffin Internet's recursive DNS servers are patched. Testing passes.

  34. Rich

    RE: Bethere?

    As any Be customer knows, their DNS is crap and you should be using OpenDNS anway :o)

  35. This post has been deleted by its author

  36. Anonymous Coward
    Thumb Down

    AT&T Refuses To Acknowledge This Is A New Vulnerability

    In case you have not seen it, here is AT&T's official statement on this vulnerability:

    "AT&T Response: US-CERT DNS Security Alert- announced July 8, 2008

    On July 8, 2008, US-CERT issued a Technical Cyber Security Alert TA08-190B with the title 'Multiple DNS implementations vulnerable to cache poisoning.' This alert describes how deficiencies in the DNS protocol and common DNS implementations facilitate DNS Cache poisoning attacks. This vulnerability only affects caching DNS servers, not authoritative DNS servers. This alert instructed administrators to contact their vendors for patches.

    The DNS community has been aware of this vulnerability for some time. CERT technical bulletin http://www.kb.cert.org/vuls/id/252735 issued in July, 2007, identified this vulnerability but at the time no patches were available from vendors.

    AT&T does not disclose the name of its DNS vendors as a security measure but has implemented a preliminary patch that was available in January, 2008. The latest patch for alert TA08-190B is currently being tested and will be deployed in the network as soon as its quality has been assured.

    AT&T employs best practices in the management of its DNS infrastructure. For example, the majority of AT&T's caching DNS infrastructures have load balancers. Load balancers decrease the risk significantly because hackers are unable to target specific DNS servers. As with all patches to software affecting AT&T's production networks and infrastructure, AT&T first tests the patches in the lab to ensure they work as expected and then certifies them before deploying them into our production infrastructure.

    Conclusion:

    Security is of paramount importance to AT&T. AT&T has a comprehensive approach to the security of its networks and supporting infrastructures. AT&T is meeting or exceeding our world-class DNS network performance measures. We will continue to monitor the situation and will deploy software upgrades, as warranted, following our structured testing and certification process."

    End of quote.

    Note that:

    1) They claim this is the same problem reported a year ago and for which they have already patched.

    2) They claim load balancers will protect against this bug. All evidence to the contrary, they have not changed their statement.

    3) They claim they do not disclose the vendor of their DNS, but also claim this is a bug in BIND which they have also patched.

    4) They do not acknowledge that this is an issue with the DNS protocol, rather they act as if it is a bug in a software application.

    Verizon patched everything on July 10th. What is taking AT&T so long?

  37. Anonymous Coward
    Thumb Down

    Not all of comcast is patched

    I'm on comcast, and I just failed the test. A little disconcerting considering they state at their test site "Note: Comcast users should not worry.". What amazes me is that these companies dont get it and carry on just as they did before....

  38. spam
    Happy

    UKOnline no longer vulnerable

    UKOnline/Easynet seem to have patched their DNS servers within the past few hours.. so all is okay here now!

  39. Christopher
    Go

    BT seems fine to me

    We have BT here (albeit a business line), and 194.72.0.98 comes up clean (haven't tried our secondary which is 194.72.9.38).

  40. Anonymous Coward
    Alert

    Verizon

    Your name server, at 68.238.96.36, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 36.

    Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds.

    --------------------------------------------------------------------------------

    Requests seen for 87bba0bc964e.toorrr.com:

    68.238.96.36:39655 TXID=27775

    68.238.96.36:39670 TXID=11599

    68.238.96.36:39646 TXID=23973

    68.238.96.36:39682 TXID=39241

    68.238.96.36:39652 TXID=32366

    Other repeat runs of the test give a port range no larger than 70, and as few as 23. Doesn't this make it easier for the bad guy to win the race, or is it the router I am sitting behind that is doing this?

  41. thomas k.

    re: Verizon

    Running the test on my Verizon connection got me the "appears to be safe" message, along with the "make sure the ports ..." bit.

    I didn't get the port range message you got, so it might well be your router settings.

  42. Jason DePriest
    Go

    AT&T U-Verse okay? Maybe?

    Your name server, at 151.164.14.196, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.

    --------------------------------------------------------------------------------

    Requests seen for 4f5029e03184.toorrr.com:

    151.164.14.196:18902 TXID=4222

    151.164.14.196:44489 TXID=45620

    151.164.14.196:2701 TXID=65443

    151.164.14.196:57187 TXID=34670

    151.164.14.196:1526 TXID=56490

    Note: dnsnode1-x4.stlsmo.sbcglobal.net [151.164.14.196]

  43. Jon Smit
    Thumb Up

    Entanet

    Appears to be sorted

    Your name server, at 195.74.113.58, appears to be safe,

    Requests seen for f3050306b5b3.toorrr.com:

    195.74.113.58:13414 TXID=52945

    195.74.113.58:49222 TXID=48220

    195.74.113.58:45941 TXID=16935

    195.74.113.58:26171 TXID=13951

    195.74.113.58:50179 TXID=10996

  44. John Dougald McCallum
    Boffin

    DNS patch

    Your list may not be that accurate AOL runs on the Carphone Warehouse servers and appears not to be suseptible to this attack.

    Boffin for obvious reasons

  45. John Dickson

    RE: Verizon and DEMON

    "Demon Internet was reported as potentially being vulnerable"

    No. It produces similar messages to that produced by Verizon e.g

    'Your name server, at 194.159.187.34, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 247.

    Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds.'

  46. John Dougald McCallum

    Looks good to go here

    Your name server, at 195.93.61.23, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.

    --------------------------------------------------------------------------------

    Requests seen for 9184eaf37373.toorrr.com:

    195.93.61.23:29828 TXID=42138

    195.93.61.23:20642 TXID=48288

    195.93.61.23:36031 TXID=14818

    195.93.61.23:51089 TXID=49774

    195.93.61.23:46036 TXID=9067

    As I said in earlier post this is Carphone whorehouse server

  47. Alan W. Rateliff, II
    Paris Hilton

    Update on AT&T Wireless

    Per dns-oarc.net,

    209.183.35.23 (alpinetdns.mycingular.net) appears to have GREAT source port randomness and GREAT transaction ID randomness.

    But it still fail's Kaminsky's (Doxpara) test.

    Paris, a great source of port randomness.

  48. RW
    Go

    Telus okay

    Somewhat to my surprise. Somebody at Telus is paying attention.

    The thing I find interesting is that some very large ISPs seem to have no mechanism in place for fast tracking critical changes. Sometimes a patch is so important and so urgent that if it makes the system fall over, that's still a better situation than running without the patch.

  49. James O'Brien

    TWTelecom here

    Your name server, at 64.128.189.114, appears vulnerable to DNS Cache Poisoning.

  50. Luke Mellor
    Thumb Up

    Grande Communications

    Looks like they have fixed theirs as well:

    Your name server, at 66.90.132.162, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.

    --------------------------------------------------------------------------------

    Requests seen for 73f58c44c681.toorrr.com:

    66.90.132.162:7606 TXID=61558

    66.90.132.162:23192 TXID=64573

    66.90.132.162:1926 TXID=37783

    66.90.132.162:58791 TXID=26127

    66.90.132.162:36230 TXID=12505

  51. Anonymous Coward
    Thumb Down

    Virgin Media may not be sorted, despite what they say

    Configuring my router to use the DNS cache at 194.168.8.100:

    Your name server, at 194.168.8.109, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 225.

    Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds.

    Requests seen for 27e658dcb4c1.toorrr.com:

    194.168.8.109:32901 TXID=41131

    194.168.8.109:32851 TXID=63188

    194.168.8.109:32796 TXID=9462

    194.168.8.109:33009 TXID=10296

    194.168.8.109:32784 TXID=60013

    And again (this time with 194.168.4.100 configured as secondary):

    Your name server, at 80.7.128.36, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 194.

    Please talk to your firewall or gateway vendor -- all are working on patches, mitigations, and workarounds.

    Requests seen for 1817ba74d9ed.toorrr.com:

    80.7.128.36:15532 TXID=36617

    80.7.128.36:15726 TXID=49120

    80.7.128.36:15605 TXID=34601

    80.7.128.36:15700 TXID=14672

    80.7.128.36:15604 TXID=50260

    Switching to OpenDNS (208.67.222.222):

    Your name server, at 208.69.34.8, appears to be safe, but make sure the ports listed below aren't following an obvious pattern.Requests seen for de290b751743.toorrr.com:

    208.69.34.8:31815 TXID=37200

    208.69.34.8:4651 TXID=52861

    208.69.34.8:54638 TXID=29577

    208.69.34.8:41802 TXID=59604

    208.69.34.8:19492 TXID=1674

    For reference,

    194.168.8.109 is winn-dnsbep-1.server.virginmedia.net

    80.7.128.36 is oxfd-dnsany-1.server.virginmedia.net

    To VirginMedia: it's no good the DNS cache randomising request ports if it's behind a NAT which just maps the ports back to something more predictable. As I understand the vulnerability, unpredictability of port numbers needs to be maintained across each network boundary, or else an attacker on the predictable side (outside the NAT in this case, if it is indeed a NAT that's the problem here and not the DNS cache) can still spoof responses.

    It's also not much good randomising ports if you're still in a 200-ish range (adding only 8 bits of uncertainty to the 16 in the TXID, when the recommendation is to go to almost 32 bits).

    Finally, there's no need to be so proud of starting work on it a month before Kaminsky published. Daniel Bernstein has been saying since at latest 2001 that DNS request ports should be randomised: http://cr.yp.to/djbdns/forgery-cost.txt

  52. Vanessa Williams

    Bell Canada is safe

    The article incorrectly states that Bell Canada is vulnerable. I used the test when I first heard about the problem and it said everything was fine. Just re-checked with the same result. As much as I despise Bell, they must have done the right thing. Either that, or the tool to check for the exploit is not working properly.

  53. Anonymous Coward
    Coat

    @ thomas k. and Steve. Verizon / Virgin Media

    Thanks. Does this mean that subscribers who are getting the "port range too narrow" or "ports may follow a predictable pattern" test error are using name servers that are not patched properly?

    Or is the test error an artifact of how NAT treats DNS lookup requests between the unwashed masses and the hopfully heavily armored DNS and LAN/WAN infrastructure of our trusty ISP of choice who shares much public space with many many NATed addresses?

    If the narrow range, or patterned port assignments test errors behind every NAT wielding ISP are still a vulnerabilty, then I must be missing something.

    I blame supernetting for the error, bring on IPV6 already!

    <orderlies quickly descend to escort the anonymous coward into a wrap-around jacket and away from the computer in the recreation room, there is great struggle>

  54. John Dickson

    Re: "port range too narrow" or "ports may follow a predictable pattern"

    Anonymous Coward said:

    "Does this mean that subscribers who are getting the "port range too narrow" or "ports may follow a predictable pattern" test error are using name servers that are not patched properly?"

    Well, my latest tests of Demon produce:

    "Your ISP's name server, 194.159.187.38, appears to be using the name server written by Nominum, which has effective protection against the newly discovered attacks despite the limited port range. Nominum is working to expand the port range for even greater protection, but there is no reason for concern at this time."

    but also

    "Your name server, at 194.159.187.34, may be safe, but the NAT/Firewall in front of it appears to be interfering with its port selection policy. The difference between largest port and smallest port was only 171."

    (which is the same as previously reported for this server)

    So now I'm confused. Are Demon using different versions of Nominum on different servers? Or is their patching not complete? Perhaps someone who is more savvy than me could explain what's going on here.

  55. JohnG

    Firewalls

    "Demon Internet was reported as potentially being vulnerable, because a Firewall or NAT in front of the DNS server "appears to be interfering with its port selection policy," according to Kaminsky's test."

    I would guess Demon's firewalls INTENTIONALLY interfere with the port selection. Our Checkpoint firewalls alter both the port and the Id number used, specifically to mitigate the issue under discussion (and the server guys have applied the necessary patch) but the Check My DNS site still thinks we are vulnerable.

  56. greg

    Swisscom's server vulnerable

    Your name server, at 195.186.1.110, appears vulnerable to DNS Cache Poisoning.

    All requests came from the following source port: 47043

    Swisscom (Switzerland) primary DNS server for ADSL customers

  57. Anonymous Coward
    Anonymous Coward

    Limited port ranges

    My understanding is that if you randomise the port but only within a range of (say) 256 ports, then you have 24 bits of randomness including TXID. So even if the attacker can only get one packet in before the valid response, then they have a better than 1 in 17 million chance of success. According to Kaminsky's blog, the attacker can make a couple of thousand attacks (on different subdomains) per second - presumably this depends mostly on connection speeds. 8 thousand seconds is over 2 hours.

    Now, 2 hours is a moderately long time to flood a server without anyone noticing. It's a very long time if there's something looking for such attacks in real time, although what a server can usefully do if it detects a series of attacks I'm not sure.

    However, if my rough calculation is orders of magnitude out in the bad direction (for instance, suppose the attacker can reliably get 100 spoof responses in before the genuine response) then I don't see how the protection is adequate. It might take under a minute of activity to poison a DNS cache. That activity might conceivably be distributed across time and/or a botnet to reduce the chances of detection. If a large botnet were to devote its time to attacking such "24 bit" DNS servers, then it would successfully poison some of them, wouldn't it?

    Perhaps Kaminsky can explain why a range of a couple of hundred ports is good enough. I haven't analysed the issue at all, I'm just repeating what I've read from Kaminsky and others. But my suspicion is that the warning is there for a reason, and the reason is that a narrow port range is not a full fix.

    On the NAT issue: it doesn't matter whether the port randomisation is done by the DNS resolver or by the NAT, except that:

    1) If the resolver is less random than the NAT, then you're somewhat more vulnerable to an attacker inside the NAT than outside (this is what happens if the NAT is fixed and the resolver isn't).

    2) If the NAT constricts the port range of the resolver, then you're somewhat more vulnerable to an attacker outside the NAT than one inside.

    Combining the two cases, if there are attackers both inside and outside the NAT then you're as protected as the worst case of port predictability. So what we want is for all resolvers and all NATs to randomise ports across as wide a range as possible.

    Presumably if there's a "bad" NAT between you and a "good" DNS server, then Kaminsky's test would report you clean (because it only sees the requests from the fixed caching resolver), but actually you'd be vulnerable even if the non-caching resolver in your OS is patched, because the randomised port choice is rendered predictable by the NAT. So depending on network topology, there may be cases where your own domestic firewall/router makes you vulnerable to an attacker inside your ISP's subnet, even though everything else is fixed. Do ISPs route packets directly from one customer IP to another? What brands of firewall/router randomise ports adequately?

    I'm sure Kaminsky will have all the answers at Black Hat. Or someone else will provide them sooner.

  58. Anonymous Coward
    Anonymous Coward

    As expected

    Your name server, at 80.58.61.250, appears vulnerable to DNS Cache Poisoning.

    Telefonica couldn't care less about its subscribers. Fortunately the show equal care as to what their subscribers do.

  59. Anonymous Coward
    Unhappy

    Sprint PCS

    This is suprising...

    Your name server, at 68.28.242.91, appears vulnerable to DNS Cache Poisoning.

    All requests came from the following source port: 45521

    Due to events outside our control, details of the vulnerability have been leaked. Please consider using a safe DNS server, such as OpenDNS. Note: Comcast users should not worry.

    --------------------------------------------------------------------------------

    Requests seen for d143efecae0d.doxdns5.com:

    68.28.242.91:45521 TXID=5971

    68.28.242.91:45521 TXID=14822

    68.28.242.91:45521 TXID=5783

    68.28.242.91:45521 TXID=39914

    68.28.242.91:45521 TXID=34212

    It is a wireless broadband link, would that be why they do not randomize the port?

  60. Steve

    Need a black Pais icon

    I am ashamed of you ElReg - only a white Paris? Please make an icon out of this so we can truly express our opinions:

    w w w.rude.com/steverudeman - take out the spaces

  61. Anonymous Coward
    Stop

    So, uh

    Just exactly how is disclosing this vulnerability to the wild making the internet safer? Maybe the name Blackhat has the insinuated connotation for these security researchers.

  62. Anonymous Coward
    Stop

    Managed networks.

    We (where I work) have the joy of outsourcing our network management to ****. This seems insanity to me, but it's obviously a choice for upper management, not us techies.

    Anyway - the responsef from **** was that we are not vulnerable because the servers only serve answers for trusted clients.

    Which totally misses the point - if you allow your clients access to the internet, then they're vulnerable.

    So - if your company has external people managing your DNS (or other core services) - don't forget to JUMP ON THEM.

    Anonymous & blanked company name for (hopefully) obvious reasons.

  63. John Goodwin
    Thumb Down

    Pony Uruguyan ISP

    I shouldn't really expect anything less to be honest.

    Average 8% packet loss and 35 UK notes a month here in sunny Montevideo for a 1.5 smeg connection ;-)

    Your name server, at 200.40.220.226, appears vulnerable to DNS Cache Poisoning.

    All requests came from the following source port: 33208

    Requests seen for 7a29f8f05811.doxdns5.com:

    200.40.220.226:33208 TXID=23352

    200.40.220.226:33208 TXID=39952

    200.40.220.226:33208 TXID=41029

    200.40.220.226:33208 TXID=3363

    200.40.220.226:33208 TXID=57739

    Thumbs down as Paris is always getting thumbs up.

  64. Paul Blonde

    Not all of Telus is ok

    Only certain regions. Also at risk in Canada are Navigata and Westel:

    204.244.3.129

    204.244.3.130

  65. Pyromancer
    Linux

    DJBDNS seems secure

    Testing my recursive DJB servers produces "great!" results, semingly (from mailing list comments) it was DJB who suggested randomising the source ports as a security measure in the first place.

    (Tux as DJB is a *nix only app)

This topic is closed for new posts.

Biting the hand that feeds IT © 1998–2019