Login
The Domain Name System (DNS) root zone will soon be getting a new record type, called ZONEMD, to further ensure the security, stability, and resiliency of the global DNS in the face of emerging new approaches to DNS operation. While this change will be unnoticeable for the vast majority of DNS operators (such as registrars, internet service providers, and organizations), it provides a valuable additional layer of cryptographic security to ensure the reliability of root zone data.
In this blog, we’ll discuss these new proposals, as well as ZONEMD. We’ll share deployment plans, how they may affect certain users, and what DNS operators need to be aware of beforehand to ensure little-to-no disruptions.
The DNS root zone is the starting point for most domain name lookups on the internet. The root zone contains delegations to nearly 1,500 top-level domains, such as .com, .net, .org, and many others. Since its inception in 1984, various organizations known collectively as the Root Server Operators have provided the service for what we now call the Root Server System (RSS). In this system, a myriad of servers respond to approximately 80 billion root zone queries each day.
While the RSS continues to perform this function with a high degree of dependability, there are recent proposals to use the root zone in a slightly different way. These proposals create some efficiencies for DNS operators, but they also introduce new challenges.
In 2020, the Internet Engineering Task Force (IETF) published RFC 8806, titled “Running a Root Server Local to a Resolver.” Along the same lines, in 2021 the Internet Corporation for Assigned Names and Numbers (ICANN) Office of the Chief Technology Officer published OCTO-027, titled “Hyperlocal Root Zone Technical Analysis.” Both proposals share the idea that recursive name servers can receive and load the entire root zone locally and respond to root zone queries directly.
But in a scenario where the entire root zone is made available to millions of recursive name servers, a new question arises: how can consumers of zone data verify that zone content has not been modified before reaching their systems?
One might imagine that DNS Security Extensions (DNSSEC) could help. However, while the root zone is indeed signed with DNSSEC, most of the records in the zone are considered non-authoritative (i.e., all the NS and glue records) and therefore do not have signatures. What about something like a Pretty Good Privacy (PGP) signature on the root zone file? That comes with its own challenge: in PGP, the detached signature is easily separated from the data. For example, there is no way to include a PGP signature over DNS zone transfer, and there is no easy way to know which version of the zone goes with the signature.
A solution to this problem comes from RFC 8976. Led by Verisign and titled “Message Digest for DNS Zones” (known colloquially as ZONEMD), this protocol calls for a cryptographic digest of the zone data to be embedded into the zone itself. This ZONEMD record can then be signed and verified by consumers of the zone data. Here’s how it works:
Each time a zone is updated, the publisher calculates the ZONEMD record by sorting and canonicalizing all the records in the zone and providing them as input to a message digest function. Sorting and canonicalization are the same as for DNSSEC. In fact, the ZONEMD calculation can be performed at the same time the zone is signed. Digest calculation necessarily excludes the ZONEMD record itself, so the final step is to update the ZONEMD record and its signatures.
A recipient of a zone that includes a ZONEMD record repeats the same calculation and compares its calculated digest value with the published digest. If the zone is signed, then the recipient can also validate the correctness of the published digest. In this way, recipients can verify the authenticity of zone data before using it.
A number of open-source DNS software products now, or soon will, include support for ZONEMD verification. These include Unbound (version 1.13.2), NSD (version 4.3.4), Knot DNS (version 3.1.0), PowerDNS Recursor (version 4.7.0) and BIND (version 9.19).
Verisign, ICANN, and the Root Server Operators are taking steps to ensure that the addition of the ZONEMD record in no way impacts the ability of the root server system to receive zone updates and to respond to queries. As a result, most internet users are not affected by this change.
Anyone using RFC 8806, or a similar technique to load root zone data into their local resolver, is unlikely to be affected as well. Software products that implement those features should be able to fully process a zone that includes the new record type, especially for reasons described below. Once the record has been added, users can take advantage of ZONEMD verification to ensure root zone data is authentic.
Users most likely to be affected are those that receive root zone data from the internic.net servers (or some other source) and use custom software to parse the zone file. Depending on how such custom software is designed, there is a possibility that it will treat the new ZONEMD record as unexpected and lead to an error condition. Key objectives of this blog post are to raise awareness of this change, provide ample time to address software issues, and minimize the likelihood of disruptions for such users.
In 2020, Verisign asked the Root Zone Evolution Review Committee (RZERC) to consider a proposal for adding data protections to the root zone using ZONEMD. In 2021, the RZERC published its recommendations in RZERC003. One of those recommendations was for Verisign and ICANN to develop a deployment plan and make the community aware of the plan’s details. That plan is summarized in the remainder of this blog post.
One attribute of a ZONEMD record is the choice of a hash algorithm used to create the digest. RFC 8976 defines two standard hash algorithms – SHA-384 and SHA-512 – and a range of “private-use” algorithms.
Initially, the root zone’s ZONEMD record will have a private-use hash algorithm. This allows us to first include the record in the zone without anyone worrying about the validity of the digest values. Since the hash algorithm is from the private-use range, a consumer of the zone data will not know how to calculate the digest value. A similar technique, known as the “Deliberately Unvalidatable Root Zone,” was utilized when DNSSEC was added to the root zone in 2010.
After a period of more than two months, the ZONEMD record will transition to a standard hash algorithm.
SHA-384 has been selected for the initial implementation for compatibility reasons.
The developers of BIND implemented the ZONEMD protocol based on an early Internet-Draft, some time before it was published as an RFC. Unfortunately, the initial BIND implementation only accepts ZONEMD records with a digest length of 48 bytes (i.e., the SHA-384 length). Since the versions of BIND with this behavior are in widespread use today, use of the SHA-512 hash algorithm would likely lead to problems for many BIND installations, possibly including some Root Server Operators.
Distribution of the zone between the Root Zone Maintainer and Root Server Operators primarily takes place via the DNS zone transfer protocol. In this protocol, zone data is transmitted in “wire format.”
The root zone is also stored and served as a file on the internic.net FTP and web servers. Here, the zone data is in “presentation format.” The ZONEMD record will appear in these files using its native presentation format. For example:
FreshRSS . 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )Some users of zone data received from the FTP and web servers might currently be using software that does not recognize the ZONEMD presentation format. These users might experience some problems when the ZONEMD record first appears. We did consider using a generic record format; however, in consultation with ICANN, we believe that the native format is a better long-term solution.
Currently, we are targeting the initial deployment of ZONEMD in the root zone for September 13, 2023. As previously stated, the ZONEMD record will be published first with a private-use hash algorithm number. We are targeting December 6, 2023, as the date to begin using the SHA-384 hash algorithm, at which point the root zone ZONEMD record will become verifiable.
Deploying ZONEMD in the root zone helps to increase the security, stability, and resiliency of the DNS. Soon, recursive name servers that choose to serve root zone data locally will have stronger assurances as to the zone’s validity.
If you’re interested in following the ZONEMD deployment progress, please look for our announcements on the DNS Operations mailing list.
The post Adding ZONEMD Protections to the Root Zone appeared first on Verisign Blog.
John Clifton Davies, a 60-year-old con man from the United Kingdom who fled the country in 2015 before being sentenced to 12 years in prison for fraud, has enjoyed a successful life abroad swindling technology startups by pretending to be a billionaire investor. Davies’ newest invention appears to be “CodesToYou,” which purports to be a “full cycle software development company” based in the U.K.
The scam artist John Bernard a.k.a. Alan John Mykailov (left) in a recent Zoom call, and a mugshot of John Clifton Davies from nearly a decade earlier.
Several articles here have delved into the history of John Bernard, the pseudonym used by a fake billionaire technology investor who tricked dozens of startups into giving him tens of millions of dollars.
John Bernard’s real name is John Clifton Davies, a convicted fraudster from the United Kingdom who is currently a fugitive from justice. For several years until reinventing himself again quite recently, Bernard pretended to be a billionaire Swiss investor who made his fortunes in the dot-com boom 20 years ago.
“The Private Office of John Bernard” let it be known to investment brokers that he had tens of millions of dollars to invest in tech startups, and he attracted a stream of new victims by offering extraordinarily generous finder’s fees to brokers who helped him secure new clients. But those brokers would eventually get stiffed because Bernard’s company would never consummate a deal.
John Bernard’s former website, where he pretended to be a billionaire tech investor.
Bernard would promise to invest millions in tech startups, and then insist that companies pay tens of thousands of dollars worth of due diligence fees up front. However, the due diligence company he insisted on using — another Swiss firm called The Inside Knowledge GmbH — also was secretly owned by Bernard, who would invariably pull out of the deal after receiving the due diligence money.
A variety of clues suggest Davies has recently adopted at least one other identity — Alan John Mykhailov — who is listed as chairman of a British concern called CodesToYou LTD, incorporated in May 2022. The CodesToYou website says the company employs talented coders in several countries, and that its programmers offer “your ultimate balance between speed, cost and quality.”
The team from CodesToYou.
In response to questions from KrebsOnSecurity, CodesToYou’s marketing manager — who gave their name only as “Zhena” — said the company was not affiliated with any John Bernard or John Clifton Davies, and maintained that CodesToYou is a legitimate enterprise.
But publicly available information about this company and its leadership suggests otherwise. Official incorporation documents from the U.K.’s Companies House represent that CodesToYou is headed by an Alan John Mykhailov, a British citizen born in March 1958.
Companies House says Mykhailov is an officer in three other companies, including one called Blackstone Corporate Alliance Ltd. According to the Swiss business tracking service business-monitor.ch, Blackstone Corporate Alliance Ltd. is currently the entity holding a decision-making role in John Bernard’s fake due diligence company — The Inside Knowledge GmbH — which is now in liquidation.
A screen shot of the stock photos and corporate-speak on John Bernard’s old website. Image: Archive.org
Also listed as a partner in Blackstone Corporate Alliance Limited is Igor Hubskyi (a.k.a. Igor Gubskyi), a Ukrainian man who was previously president of The Inside Knowledge GmbH.
The CodesToYou website says the company’s marketing team lead is Maria Yakovleva, and the photo of this employee matches the profile for the LinkedIn account name “Maria Y.” That same LinkedIn profile and photo previously listed Maria by a different first and last name — Mariya Kulikova; back then, Ms. Kulikova’s LinkedIn profile said she was an executive assistant in The Private Office of Mr. John Bernard.
Companies House lists Alan John Mykhailov as a current officer in two other companies, including Frisor Limited, and Ardelis Solutions Limited. A cached copy of the now-defunct Ardelis Solutions website says it was a private equity firm.
CodesToYou’s Maria also included Ardelis Solutions in the work history section of her LinkedIn resume. That is, until being contacted by this author on LinkedIn, after which Maria’s profile picture and any mention of Ardelis Solutions were deleted.
Listed as head of business development at CodesToYou is David Bruno, a Canadian man whose LinkedIn profile says he is founder of an organization called “World Privacy Resource.” As KrebsOnSecurity reported in 2020, Bruno was at the time promoting himself as the co-CEO of a company called SafeSwiss Secure Communication AG, and the founder of another tech startup called Secure Swiss Data.
Secure Swiss Data’s domain — secureswissdata.com — is a Swiss concern that sells encrypted email and data services. According to DomainTools.com, that website name was registered in 2015 by The Inside Knowledge GmbH. In February 2020, a press release announced that Secure Swiss Data was purchased in an “undisclosed multimillion buyout” by SafeSwiss Secure Communication AG.
A cached copy of the Ardelis Solutions website, which said it was a private equity firm and included similar stock images as John Bernard’s investment website.
When reached in 2020 and asked about his relationship to Mr. Bernard, Mr. Bruno said the two were business partners and that he couldn’t imagine that Mr. Bernard would be involved in anything improper. To this day Mr. Bruno is the only person I’ve spoken to who has had anything positive to say about Mr. Bernard.
Mr. Bruno did not respond to requests for comment this time around, but his LinkedIn profile no longer makes any mention of Secure Swiss Data or SafeSwiss — both companies he claimed to run for many years. Nor does it mention CodesToYou. However, Mr. Bruno’s former company SafeSwiss is listed as one of the six “portfolio” companies whose services are promoted on the CodesToYou website.
In mid-2021, Bruno announced he was running for public office in Ontario.
“The Kenora resident is no stranger to the government as he contributed to Canada’s new Digital Charter, Bill C-11, which is a new Cyber Security policy,” reported Drydennow.com, a news website that covers Northwestern Ontario. Drydennow says the next federal election is expected to be held on or before Oct. 16, 2023.
John Clifton Davies was convicted in 2015 of swindling businesses throughout the U.K. that were struggling financially and seeking to restructure their debt. For roughly six years, Davies ran a series of firms that pretended to offer insolvency services, but instead simply siphoned what little remaining money these companies had.
The very first entity mentioned in the technology portfolio advertised on the CodesToYou website is called “MySolve,” and it purports to offer a “multi-feature platform for insolvency practitioners.”
Mr. Davies’ fourth wife, Iryna Davies, is listed as a director of one of the insolvency consulting businesses in the U.K. that was part of John Davies’ 2015 fraud conviction. Prior to his trial for fraud, Davies served 16 months in jail before being cleared of murdering his third wife on their honeymoon in India: Colette Davies, 39, died after falling 80 feet from a viewing point at a steep gorge in the Himachal Pradesh region of India.
Mr. Davies was charged with murder and fraud after he attempted to collect GBP 132,000 in her life insurance payout, but British prosecutors ultimately conceded they did not have enough evidence to convict him.
The scams favored by Davies and his alter egos are smart because he never approaches investors directly; rather, investors are incentivized to put his portfolio in front of tech firms seeking financial backing. And all the best cons begin as an idea or possibility planted in the target’s mind.
It’s also a reliable scam because companies bilked by small-time investment schemes rarely pursue legal action, mainly because the legal fees involved can quickly surpass the losses. On top of that, many victims will likely be too ashamed to admit their duping. Victims who do press their case in court and win then face the daunting challenge of collecting damages from a slew of ephemeral shell corporations.
The latest Bernard victim to speak publicly — a Norwegian company hoping to build a fleet of environmentally friendly shipping vessels — is now embroiled in a lawsuit over a deal gone bad. As part of that scam, Bernard falsely claimed to have secured $100 million from six other wealthy investors, including the founder of Uber and the artist Abel Makkonen Tesfaye, better known as The Weeknd.
If you liked this story, check out my previous reporting on John Bernard/Davies:
Due Diligence That Money Can’t Buy
Who is Tech Investor John Bernard?
Promising Infusions of Cash, Fake Investor John Bernard Walked Away With $30 Million
Investment Scammer John Davies Reinvents Himself?
Fake Investor John Bernard Sinks Norwegian Green Shipping Dreams
Related tags
Every few months, an important ceremony takes place. It’s not splashed all over the news, and it’s not attended by global dignitaries. It goes unnoticed by many, but its effects are felt across the globe. This ceremony helps make the internet more secure for billions of people.
This unique ceremony began in 2010 when Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), and the U.S. Department of Commerce’s National Telecommunications and Information Administration collaborated – with input from the global internet community – to deploy a technology called Domain Name System Security Extensions (DNSSEC) to the Domain Name System (DNS) root zone in a special ceremony. This wasn’t a one-off occurrence in the history of the DNS, though. Instead, these organizations developed a set of processes, procedures, and schedules that would be repeated for years to come. Today, these recurring ceremonies help ensure that the root zone is properly signed, and as a result, the DNS remains secure, stable, and resilient.
In this blog, we take the opportunity to explain these ceremonies in greater detail and describe the critical role that Verisign is honored to perform.
DNSSEC is a series of technical specifications that allow operators to build greater security into the DNS. Because the DNS was not initially designed as a secure system, DNSSEC represented an essential leap forward in securing DNS communications. Deploying DNSSEC allows operators to better protect their users, and it helps to prevent common threats such as “man-in-the-middle” attacks. DNSSEC works by using public key cryptography, which allows zone operators to cryptographically sign their zones. This allows anyone communicating with and validating a signed zone to know that their exchanges are genuine.
The root zone, like most signed zones, uses separate keys for zone signing and for key signing. The Key Signing Key (KSK) is separate from the Zone Signing Key (ZSK). However, unlike most zones, the root zone’s KSK and ZSK are operated by different organizations; ICANN serves as the KSK operator and Verisign as the ZSK operator. These separate roles for DNSSEC align naturally with ICANN as the Root Zone Manager and Verisign as the Root Zone Maintainer.
In practice, the KSK/ZSK split means that the KSK only signs the DNSSEC keys, and the ZSK signs all the other records in the zone. Signing with the KSK happens infrequently – only when the keys change. However, signing with the ZSK happens much more frequently – whenever any of the zone’s other data changes.
Something to keep in mind before we go further: remember that DNSSEC utilizes public key cryptography, in which keys have both a private and public component. The private component is used to generate signatures and must be guarded closely. The public component is used to verify signatures and can be shared openly. Good cryptographic hygiene says that these keys should be changed (or “rolled”) periodically.
In DNSSEC, changing a KSK is generally difficult, whereas changing a ZSK is relatively easy. This is especially true for the root zone where a KSK rollover requires all validating recursive name servers to update their copy of the trust anchor. Whereas the first and only KSK rollover to date happened after a period of eight years, ZSK rollovers take place every three months. Not coincidentally, this is also how often root zone key signing ceremonies take place.
The notion of holding a “ceremony” for such an esoteric technical function may seem strange, but this ceremony is very different from what most people are used to. Our common understanding of the word “ceremony” brings to mind an event with speeches and formal attire. But in this case, the meaning refers simply to the formality and ritual aspects of the event.
There are two main reasons for holding key signing ceremonies. One is to bring participants together so that everyone may transparently witness the process. Ceremony participants include ICANN staff, Verisign staff, Trusted Community Representatives (TCRs), and external auditors, plus guests on occasion.
The other important reason, of course, is to generate DNSSEC signatures. Occasionally other activities take place as well, such as generating new keys, retiring equipment, and changing TCRs. In this post, we’ll focus only on the signature generation procedures.
A month or two before each ceremony, Verisign generates a file called the Key Signing Request (KSR). This is an XML document which includes the set of public key records (both KSK and ZSK) to be signed and then used during the next calendar quarter. The KSR is securely transmitted from Verisign to the Internet Assigned Numbers Authority (IANA), which is a function of ICANN that performs root zone management. IANA securely stores the KSR until it is needed for the upcoming key signing ceremony.
Each quarter is divided into nine 10-day “slots” (for some quarters, the last slot is extended by a day or two) and the XML file contains nine key “bundles” to be signed. Each bundle, or slot, has a signature inception and expiration timestamp, such that they overlap by at least five days. The first and last slots in each quarter are used to perform ZSK rollovers. During these slots we publish two ZSKs and one KSK in the root zone.
The root zone KSK private component is held inside secure Hardware Security Modules (HSMs). These HSMs are stored inside locked safes, which in turn are kept inside locked rooms. At a key signing ceremony, the HSMs are taken out of their safes and activated for use. This all occurs according to a pre-defined script with many detailed steps, as shown in the figure below.
Also stored inside the safe is a laptop computer, its operating system on non-writable media (i.e., DVD), and a set of credentials for the TCRs, stored on smart cards and locked inside individual safe deposit boxes. Once all the necessary items are removed from the safes, the equipment can be turned on and activated.
The laptop computer is booted from its operating system DVD and the HSM is connected via Ethernet for data transfer and serial port for console logging. The TCR credentials are used to activate the HSM. Once activated, a USB thumb drive containing the KSR file is connected to the laptop and the signing program is started.
The signing program reads the KSR, validates it, and then displays information about the keys about to be signed. This includes the signature inception and expiration timestamps, and the ZSK key tag values.
Validate and Process KSR /media/KSR/KSK46/ksr-root-2022-q4-0.xml...
# Inception Expiration ZSK Tags KSK Tag(CKA_LABEL)
1 2022-10-01T00:00:00 2022-10-22T00:00:00 18733,20826
2 2022-10-11T00:00:00 2022-11-01T00:00:00 18733
3 2022-10-21T00:00:00 2022-11-11T00:00:00 18733
4 2022-10-31T00:00:00 2022-11-21T00:00:00 18733
5 2022-11-10T00:00:00 2022-12-01T00:00:00 18733
6 2022-11-20T00:00:00 2022-12-11T00:00:00 18733
7 2022-11-30T00:00:00 2022-12-21T00:00:00 18733
8 2022-12-10T00:00:00 2022-12-31T00:00:00 18733
9 2022-12-20T00:00:00 2023-01-10T00:00:00 00951,18733
...PASSED.
It also displays an SHA256 hash of the KSR file and a corresponding “PGP (Pretty Good Privacy) Word List.” The PGP Word List is a convenient and efficient way of verbally expressing hexadecimal values:
SHA256 hash of KSR:
ADCE9749F3DE4057AB680F2719B24A32B077DACA0F213AD2FB8223D5E8E7CDEC
>> ringbolt sardonic preshrunk dinosaur upset telephone crackdown Eskimo rhythm gravity artist celebrate bedlamp pioneer dogsled component ruffled inception surmount revenue artist Camelot cleanup sensation watchword Istanbul blowtorch specialist trauma truncated spindle unicorn <<
At this point, a Verisign representative comes forward to verify the KSR. The following actions then take place:
The signing program outputs a new XML document, called the Signed Key Response (SKR). This document contains signatures over the DNSKEY resource record sets in each of the nine slots. The SKR is saved to a USB thumb drive and given to a member of the Root Zone KSK Operations Security team. Usually sometime the next day, IANA securely transmits the SKR back to Verisign. Following several automatic and manual verification steps, the signature data is imported into Verisign’s root zone management system for use at the appropriate times in the next calendar quarter.
Keeping the internet’s DNS secure, stable, and resilient is a crucial aspect of Verisign’s role as the Root Zone Maintainer. We are honored to participate in the key signing ceremonies with ICANN and the TCRs and do our part to help the DNS operate as it should.
For more information on root key signing ceremonies, visit the IANA website. Visitors can watch video recordings of previous ceremonies and even sign up to witness the next ceremony live. It’s a great resource, and a unique opportunity to take part in a process that helps keep the internet safe for all.
The post Verisign’s Role in Securing the DNS Through Key Signing Ceremonies appeared first on Verisign Blog.
