![\"\"](\"https:\/\/domainsure.com\/wp-content\/uploads\/2024\/08\/duckstarget-herrings.jpg\")
<\/h2>\n<\/h2>\nOn July 31st, security journalist Brian Krebs published an article<\/a> about a DNS vulnerability dubbed “Sitting Duck”, which claimed:<\/p>\n “More than a million domain names \u2014 including many registered by Fortune 100 firms and brand protection companies \u2014 are vulnerable to takeover by cybercriminals thanks to authentication weaknesses at a number of large web hosting providers and domain registrars, new research finds.”<\/em><\/p><\/blockquote>\n The research was a report via Infoblox<\/a> titled “Who Knew Domain Hijacking Was So Easy?”<\/strong><\/p>\n Because this was a DNS story, I was tagged several times on LinkedIn – where a lengthy thread had ensued<\/a> – as well as via email by readers who thought it was decent material for our #AxisOfEasy tech digest<\/a> over on the easyDNS side of the shop.<\/p>\n Before long it was posted to Hackernews replete with a long comment thread<\/a> that was rife with Gel-Mann Amnesia Effect.<\/p>\n It’s basically this:<\/p>\n Somebody registers a domain name, heads over to some third party service that ends up hosting the DNS and sets up their zone on their nameservers.<\/p>\n That could be a web host, a third-party DNS hosting provider, a CDN – anybody who is\u00a0not\u00a0<\/em>the registrar for the domain.<\/p>\n Time passes.<\/p>\n Things change.<\/p>\n Eventually, events don’t work out as planned – the project fizzles, the team is dissolved, the product gets discontinued or the marketing effort ends. The account on that third-party provider gets shut down – either by the client, or by the vendor on service expiry – it doesn’t matter.<\/p>\n The domain, however, remains<\/em> delegated to that provider’s nameservers –\u00a0and that’s\u00a0<\/em>the “Sitting Duck”.<\/p>\n It means that anybody who figures out that there’s this otherwise live domain (“live” in the sense that it’s registration is still current, and may even be pre-paid for years into the future), is just sitting there, pointing at those nameservers and there’s no zone on those nameservers to answer any residual queries that may come in.<\/p>\n You can even see via services like Ahrefs<\/strong> or Semrush<\/strong> which domains have pre-existing backlinks, and can get a sense for which ones would still have residual traffic.<\/p>\n So\u00a0if\u00a0<\/em>that provider allows somebody, anybody, to walk in the front door, create an account, and add that very same domain to their new account – they can now create a zone for it using the providers DNS management panel and make it do whatever they want:<\/p>\n Those are comparatively benign albeit opportunistic uses.<\/p>\n But they could also set up phishing sites<\/strong> that mimic the original brand, distribute malware<\/em> or otherwise leverage the trust of the actual registrant for nefarious purposes – this is the crux of the Krebs article as well as the Infoblox report.<\/p>\n This is a real issue, but it’s a somewhat of a misnomer to think of it in terms of a DNS vulnerability\u00a0<\/em>per se.<\/p>\n The DNS infrastructure is working exactly as advertised. There are is no DNS flaw being exploited that is enabling this.<\/p>\n (…and what you can do about it)<\/p>\n While Krebs mentioned previous instances of this from 2019, this has been reported on even earlier – in 2016 Matthew Bryant reported on this<\/a> and even earlier, in 2014 I wrote on the same subject from the DNS provider side of the fence over on CircleID<\/a> – where I outlined how DNS hosts need the ability to “disavow” domain delegations after somebody used one to DDoS various DNS providers in a spate of DNS reflection attacks.<\/p>\n Lame delegations have been around as long as DNS itself has – and this aspect of it does not point to some kind of flaw as much as it does poor management practices.<\/p>\n We here at easyDNS\/Domainsure<\/strong> are both an anycast DNS provider and an enterprise domain registrar, wearing both hats gives us a unique perspective.<\/p>\n The editorial slant in the Krebs article is decidedly pointed against DNS providers as both facilitating and somehow responsible for the proliferation of “Sitting Ducks” – with multiple references to “exploitable DNS providers”.<\/p>\n Krebs is missing the point: what is\u00a0exploitable<\/em> are the\u00a0domain names<\/em> not the providers – and what makes\u00a0domain names exploitable are domain\u00a0registrants<\/em>\u00a0who have lost the plot when it comes to their own portfolio and\u00a0the registrars<\/em> who are the only entities that have any control over where those domains point.<\/p>\n A comparable analogy would be blaming GPS navigation systems for drivers who leave their vehicles unlocked with the keys in the ignition – enabling thieves to drive off with other people’s cars and commit all kinds of mayhem with them.<\/p>\n As alluded above, the\u00a0only\u00a0entities who can actually do anything about what nameservers any given domain is delegated to are the\u00a0registrars.<\/em><\/p>\n It was somewhat ironic in some of the online discussions around this issue to see certain self-described “high end”, “exclusive”, “corporate” “brand protection agencies” (read: registrars) lament that they were powerless to do anything about it when their Fortune 500 clients were being exploited in this manner.<\/p>\n They’re\u00a0the only<\/em> ones who can truly act – by monitoring their own clients’ nameserver delegations for lame delegations and then either notifying or actively parking those domains somewhere safe. This is something Domainsure does – I’m not sure why other enterprise registrars think this is out-of-scope.<\/p>\n Again, “Sitting Duck” is 100% the responsibility of the domain owner<\/strong> who can either be empowered, or ignored, by their registrars.\u00a0<\/em><\/p>\n Domainsure<\/strong> proactively monitors<\/em> over 27 specific touchpoints across hundreds of data sources on a given domain, from out-of-sync serial numbers across nameservers, to changes in the nameserver delegation or changes in the open ports on their public facing hostnames – that’s on top of looking for external\u00a0<\/em>threats like newly created typosquats, homoglyph attacks and active phishing domains, or issues like being listed in any realtime blacklists (RBL monitoring).<\/p>\n <\/p>\n <\/p>\n Said differently, had any of the Fortune 100 brands cited in the Krebs article had been using Domainsure to manage their portfolio, they would have known about their exposure years ago – either from their analytics or from their account manager, rather than reading about it on LinkedIn or Hackernews.<\/p>\n <\/p>\n There were a lot of comments – and at one point Krebs himself suggested this – that this is an easy problem to solve by simply requiring a TXT or CNAME record verification before accepting a DNS zone, “just like the standard practice with SSL certs and numerous other web apps”.<\/p>\n How exactly would that work when it comes to provisioning DNS\u00a0with the\u00a0<\/em>DNS provider?<\/p>\n You would need to publish a DNS record before your DNS provider will publish the DNS record?<\/p>\n It\u00a0is<\/em> possible – and relatively easy\u00a0<\/em>for DNS providers to mitigate against this and preempt this problem that somebody else created for them.<\/p>\n #1) Providers can monitor their own nameservers for lame delegations and create placeholder entries in their systems to block them from being added arbitrarily, something we’ve been doing for years at easyDNS.<\/p>\n #2) If a domain is already delegated to their nameservers when its being onboarded – and if it’s not\u00a0<\/em>already in a local user account (or a known lame delegation), then force the user adding the domain to update their nameserver delegation with a verification hostname in order to prove their rights over the domain (this was mentioned in the Infobox paper as well).<\/p>\n But the problem itself is the 100% the responsibility of the domain owners<\/strong>, and to varying degrees a function of their registrar<\/em><\/strong> \u2013 who is the only<\/em> entity that has any control over it.<\/span> Managing all the moving parts of even a single, production domain can be unwieldily – add together a portfolio of hundreds or even thousands and the complexity grows exponentially and can\u00a0 easily become overwhelming.<\/p>\n The exigencies of managing these IP assets goes beyond simplistic “brand protection” (which is basically, registering all the domains in all the TLDs) and enters into the realm of data analytics, cybersecurity, dark-web scanning and dependency monitoring.<\/p>\n <\/p>\n August 7, 2024<\/em> Four key points about the “sudden” emergence of this vulnerability – and how to mitigate it. On July 31st, security journalist Brian Krebs published an article about a DNS vulnerability dubbed “Sitting Duck”, which claimed: “More than […]<\/p>\n","protected":false},"author":3,"featured_media":1042,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_robots_primary_cat":"none","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","content-type":"","_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[7,1],"tags":[35,30,33,31,34,32],"class_list":{"0":"post-1023","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-articles","8":"category-news","9":"tag-brand-protection","10":"tag-brian-krebs","11":"tag-domain-hijacking","12":"tag-gell-man-amnesia-effect","13":"tag-registrars","14":"tag-sitting-duck","15":"entry"},"acf":[],"_links":{"self":[{"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/posts\/1023","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/comments?post=1023"}],"version-history":[{"count":36,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/posts\/1023\/revisions"}],"predecessor-version":[{"id":1068,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/posts\/1023\/revisions\/1068"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/media\/1042"}],"wp:attachment":[{"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/media?parent=1023"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/categories?post=1023"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/domainsure.com\/wp-json\/wp\/v2\/tags?post=1023"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What exactly is\u00a0<\/em>the “Sitting Duck” vulnerability?<\/h2>\n
![\"\"](\"https:\/\/domainsure.com\/wp-content\/uploads\/2024\/08\/delegation.png\")
<\/p>\n\n
Here are four key takeaways on the seemingly sudden emergence of “Sitting Duck”:<\/h2>\n
Takeway #1: This is not new. It has been around a long time<\/h3>\n
Takeaway #2: That this is not<\/em> some kind of DNS security vulnerability on the part of DNS operators<\/h3>\n
<\/div>\n\nTakeway #3: It’s the registrars<\/em> who are the best entities who can effectively preempt this<\/h3>\n
![\"\"](\"https:\/\/domainsure.com\/wp-content\/uploads\/2024\/08\/Screenshot-2024-08-06-at-2.32.39\u202fPM-e1722969180879.png\")
<\/p>\nTakeway #4: No, there isn’t some kind of obvious in-band validation that fixes this<\/h3>\n
![\"\"](\"https:\/\/domainsure.com\/wp-content\/uploads\/2024\/08\/validate-dns-txt-record.png\")
<\/p>\nHow does one effectively mitigate “Sitting Duck”?<\/h2>\n
\n<\/span><\/p>\n
\n
\nMark Jeftovic, founder & CEO, Domainsure Risk Intelligence.
\nmarkjr@domainsure.com<\/em><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"