Login
The launch of .web top-level domain is once again at risk of being delayed by baseless procedural maneuvering.
On May 2, the Internet Corporation for Assigned Names and Numbers (ICANN) Board of Directors posted a decision on the .web matter from its April 30 meeting, which found “that NDC (Nu Dotco LLC) did not violate the Guidebook or the Auction Rules” and directed ICANN “to continue processing NDC’s .web application,” clearing the way for the delegation of .web. ICANN later posted a preliminary report from this meeting showing that the Board vote on the .web decision was without objection.
Less than 24 hours later, however, Altanovo (formerly Afilias) – a losing bidder whose repeatedly rejected claims already have delayed the delegation of .web for more than six years – dusted off its playbook from 2018 by filing yet another ICANN Cooperative Engagement Process (CEP), beginning the cycle of another independent review of the Board’s decision, which last time cost millions of dollars and resulted in years of delay.
Under ICANN rules, a CEP is intended to be a non-binding process designed to efficiently resolve or narrow disputes before the initiation of an Independent Review Process (IRP). ICANN places further actions on hold while a CEP is pending. It’s an important and worthwhile aspect of the multistakeholder process…when used in good faith.
But that does not appear to be what is happening here. Altanovo and its backers initiated this repeat CEP despite the fact that it lost a fair, ICANN-sponsored auction; lost, in every important respect, the IRP; lost its application for reconsideration of the IRP (which it was sanctioned for filing, and which was determined to be frivolous by the IRP panel); and has now lost before the ICANN Board.
The Board’s decision expressly found that these disputes “have delayed the delegation of .web for more than six years” and already cost each of the parties, including ICANN, “millions of dollars in legal fees.”
Further delay appears to be the only goal of this second CEP – and any follow-on IRP – because no one could conclude in good faith that an IRP panel would find that the thorough process and decision on .web established in the Board’s resolutions and preliminary report violated ICANN’s bylaws. At the end of the day, all that will be accomplished by this second CEP and a second IRP is continued delay, and delay for delay’s sake amounts to an abuse of process that threatens to undermine the multistakeholder processes and the rights of NDC and Verisign.
ICANN will, no doubt, follow its processes for resolving the CEP and any further procedural maneuvers attempted by Altanovo. But, given Altanovo’s track record of losses, delays, and frivolous maneuvering since the 2016 .web auction, a point has been reached when equity demands that this abuse of process not be allowed to thwart NDC’s right, as determined by the Board, to move ahead on its .web application.
The post Will Altanovo’s Maneuvering Continue to Delay .web? appeared first on Verisign Blog.
For Murray Green, working for a company that is a steward of critical internet infrastructure is a mission that he can get behind. Green, a senior engineering manager at Verisign, is a U.S. Army veteran who served during Operation Desert Storm and sees stewardship as a lifelong mission. In both roles, he has stayed focused on the success of the mission and cultivating great teamwork.
Teamwork is something that Laura Street, a software engineer and U.S. Air Force veteran, came to appreciate through her military service. It was then that she learned to appreciate how people from different backgrounds can work together on missions by finding their commonalities.
While military and civilian roles are very different, Verisign appeals to many veterans because of the mission-driven nature of the work we do.
Green and Street are two of the many veterans who have chosen to apply their military experience in a civilian career at Verisign. Both say that the work is not only rewarding to them, but to anyone who depends on Verisign’s commitment in helping to maintain the security, stability, and resiliency of the Domain Name System (DNS) and the internet.
At Verisign, we celebrate Military Appreciation Month by paying tribute to those who have served and recognizing how fortunate we are to work alongside amazing veterans whose contributions to our work provide enormous value.
Before joining the military, Murray Green studied electrical engineering but soon realized that his true passion was computer science. Looking for a way to pay for school and explore and excel as a Programmer Analyst, he turned to the U.S. Army.
He served more than four years at the Walter Reed Army Medical Center in Washington as the sole programmer for military personnel, using a proprietary language to maintain a reporting system that supplied data analysis. It was a role that helped him recognize the importance of data to any mission – whether for the U.S. Army or a company like Verisign.
At Walter Reed, he helped usher in the age of client-server computing, which dramatically reduced data processing time. “Around this time, personal computers connected to mini servers were just coming online so, using this new technology, I was able to unload data from the mainframe and bring it down to minicomputers running programs locally, which resulted in tasks being completed without the wait times associated with conventional mainframe computing,” he said. “I was there at the right time.”
His work led him to receive the Meritorious Service Medal, recognizing his expertise in the proprietary programming language that was used to assist in preparation for Operation Desert Storm, the first mobilization of U.S. Army personnel since Vietnam.
In the military, he also came to understand the importance of leadership – “providing purpose, direction, and motivation to accomplish the mission and improve the organization.”
Green has been at Verisign for over 20 years, starting off in the registry side of the business. In that role, he helped maintain the .com/.net top level-domain (TLD) name database, which at the time, held 5 million domain names. Today, he still oversees this database, managing a highly skilled team that has helped provide uninterrupted resolution service for .com and .net for over a quarter of a century.
Street had been in medical school, looking for a way to pay for her continued education, when she heard about the military’s Health Professional Scholarship Program and turned to the U.S. Air Force.
“I met some terrific people in the military,” she said. “My favorite experiences involved working with people who cared about others and were able to motivate them with positivity.” But it was the sense of teamwork she encountered in the military that left a lasting impression.
“There’s a sense of accountability and concern for others,” she said. “You help one another.”
While working in the Education and Training department, she had been working with a support team to troubleshoot a video that wasn’t loading properly and was impressed with how the developers worked to fix the problem. She immediately took an interest in programming and enrolled in night classes at a local community college. After completing her service in the U.S. Air Force, she went back to school to pursue a bachelor’s degree in computer science.
She’s been at Verisign for two years and, while the job itself is rewarding because it taps into so many of her interests – from Java programming to network protection and packet analysis – it was the chemistry with the team that was most enticing about the role.
“I felt as at-ease as one can possibly feel during a technical interview,” she said. “I got the sense that these were people who I would want to work with.
Street credits the military for teaching her valuable communication and teamwork skills that she continues to apply in her role, which focuses on keeping the .com and .net top-level-domains available around the clock, around the world.
Both Green and Street encourage service members to stay focused on the success of their personal missions and the teamwork they learned in the military, and to leverage those skills in the civilian world. Use your service as a selling point and understand that companies value that background more than you think, they said.
“Being proud of the service we provide to others and paying attention to details allows us at Verisign to make a global difference,” Green said. “The veterans on our team bring an incredible skillset that is highly valued here. I know that I’m a part of an incredible team at Verisign.”
Verisign is proud to create career opportunities where veterans can apply their military training. To learn more about our current openings, visit Verisign Careers.
The post Verisign Honors Vets in Technology For Military Appreciation Month appeared first on Verisign Blog.
This blog was also published by APNIC.
With so much traffic on the global internet day after day, it’s not always easy to spot the occasional irregularity. After all, there are numerous layers of complexity that go into the serving of webpages, with multiple companies, agencies and organizations each playing a role.
That’s why when something does catch our attention, it’s important that the various entities work together to explore the cause and, more importantly, try to identify whether it’s a malicious actor at work, a glitch in the process or maybe even something entirely intentional.
That’s what occurred last year when Internet Corporation for Assigned Names and Numbers staff and contractors were analyzing names in Domain Name System queries seen at the ICANN Managed Root Server, and the analysis program ran out of memory for one of their data files. After some investigating, they found the cause to be a very large number of mysterious queries for unique names such as f863zvv1xy2qf.surgery, bp639i-3nirf.hiphop, qo35jjk419gfm.net and yyif0aijr21gn.com.
While these were queries for names in existing top-level domains, the first label consisted of 12 or 13 random-looking characters. After ICANN shared their discovery with the other root server operators, Verisign took a closer look to help understand the situation.
One of the first things we noticed was that all of these mysterious queries were of type NS and came from one autonomous system network, AS 15169, assigned to Google LLC. Additionally, we confirmed that it was occurring consistently for numerous TLDs. (See Fig. 1)
Although this phenomenon was newly uncovered, analysis of historical data showed these traffic patterns actually began in late 2019. (See Fig. 2)
Perhaps the most interesting discovery, however, was that these specific query names were not also seen at the .com and .net name servers operated by Verisign. The data in Figure 3 shows the fraction of queried names that appear at A-root and J-root and also appear on the .com and .net name servers. For second-level labels of 12 and 13 characters, this fraction is essentially zero. The graphs also show that there appears to be queries for names with second-level label lengths of 10 and 11 characters, which are also absent from the TLD data.
The final mysterious aspect to this traffic is that it deviated from our normal expectation of caching. Remember that these are queries to a root name server, which returns a referral to the delegated name servers for a TLD. For example, when a root name server receives a query for yyif0aijr21gn.com, the response is a list of the name servers that are authoritative for the .com zone. The records in this response have a time to live of two days, meaning that the recursive name server can cache and reuse this data for that amount of time.
However, in this traffic we see queries for .com domain names from AS 15169 at the rate of about 30 million per day. (See Fig. 4) It is well known that Google Public DNS has thousands of backend servers and limits TTLs to a maximum of six hours. Assuming 4,000 backend servers each cached a .com referral for six hours, we might expect about 16,000 queries over a 24-hour period. The observed count is about 2,000 times higher by this back-of-the-envelope calculation.
From our initial analysis, it was unclear if these queries represented legitimate end-user activity, though we were confident that source IP address spoofing was not involved. However, since the query names shared some similarities to those used by botnets, we could not rule out malicious activity.
These findings were presented last year at the DNS-OARC 35a virtual meeting. In the conference chat room after the talk, the missing piece of this puzzle was mentioned by a conference participant. There is a Google webpage describing its public DNS service that talks about prepending nonce (i.e., random) labels for cache misses to increase entropy. In what came to be known as “the Kaminsky Attack,” an attacker can cause a recursive name server to emit queries for names chosen by the attacker. Prepending a nonce label adds unpredictability to the queries, making it very difficult to spoof a response. Note, however, that nonce prepending only works for queries where the reply is a referral.
In addition, Google DNS has implemented a form of query name minimization (see RFC 7816 and RFC 9156). As such, if a user requests the IP address of www.example.com and Google DNS decides this warrants a query to a root name server, it takes the name, strips all labels except for the TLD and then prepends a nonce string, resulting in something like u5vmt7xanb6rf.com. A root server’s response to that query is identical to one using the original query name.
Now, we are able to explain nearly all of the mysterious aspects of this query traffic from Google. We see random second-level labels because of the nonce strings that are designed to prevent spoofing. The 12- and 13-character-long labels are most likely the result of converting a 64-bit random value into an unpadded ASCII label with encoding similar to Base32. We don’t observe the same queries at TLD name servers because of both the nonce prepending and query name minimization. The query type is always NS because of query name minimization.
With that said, there’s still one aspect that eludes explanation: the high query rate (2000x for .com) and apparent lack of caching. And so, this aspect of the mystery continues.
Even though we haven’t fully closed the books on this case, one thing is certain: without the community’s teamwork to put the pieces of the puzzle together, explanations for this strange traffic may have remained unknown today. The case of the mysterious DNS root query traffic is a perfect example of the collaboration that’s required to navigate today’s ever-changing cyber environment. We’re grateful and humbled to be part of such a dedicated community that is intent on ensuring the security, stability and resiliency of the internet, and we look forward to more productive teamwork in the future.
The post More Mysterious DNS Root Query Traffic from a Large Cloud/DNS Operator appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the fourth quarter of 2021 closed with 341.7 million domain name registrations across all top-level domains, an increase of 3.3 million domain name registrations, or 1.0%, compared to the third quarter of 2021.1,2 Domain name registrations have increased by 1.6 million, or 0.5%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the fourth quarter of 2021, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
The post Verisign Q4 2021 The Domain Name Industry Brief: 341.7 Million Domain Name Registrations in the Fourth Quarter of 2021 appeared first on Verisign Blog.
The Domain Name System has provided the fundamental service of mapping internet names to addresses from almost the earliest days of the internet’s history. Billions of internet-connected devices use DNS continuously to look up Internet Protocol addresses of the named resources they want to connect to — for instance, a website such as blog.verisign.com. Once a device has the resource’s address, it can then communicate with the resource using the internet’s routing system.
Just as ensuring that DNS is secure, stable and resilient is a priority for Verisign, so is making sure that the routing system has these characteristics. Indeed, DNS itself depends on the internet’s routing system for its communications, so routing security is vital to DNS security too.
To better understand how these challenges can be met, it’s helpful to step back and remember what the internet is: a loosely interconnected network of networks that interact with each other at a multitude of locations, often across regions or countries.
Packets of data are transmitted within and between those networks, which utilize a collection of technical standards and rules called the IP suite. Every device that connects to the internet is uniquely identified by its IP address, which can take the form of either a 32-bit IPv4 address or a 128-bit IPv6 address. Similarly, every network that connects to the internet has an Autonomous System Number, which is used by routing protocols to identify the network within the global routing system.
The primary job of the routing system is to let networks know the available paths through the internet to specific destinations. Today, the system largely relies on a decentralized and implicit trust model — a hallmark of the internet’s design. No centralized authority dictates how or where networks interconnect globally, or which networks are authorized to assert reachability for an internet destination. Instead, networks share knowledge with each other about the available paths from devices to destination: They route “by rumor.”
Under the Border Gateway Protocol, the internet’s de-facto inter-domain routing protocol, local routing policies decide where and how internet traffic flows, but each network independently applies its own policies on what actions it takes, if any, with data that connects through its network.
BGP has scaled well over the past three decades because 1) it operates in a distributed manner, 2) it has no central point of control (nor failure), and 3) each network acts autonomously. While networks may base their routing policies on an array of pricing, performance and security characteristics, ultimately BGP can use any available path to reach a destination. Often, the choice of route may depend upon personal decisions by network administrators, as well as informal assessments of technical and even individual reliability.
Two prominent types of operational and security incidents occur in the routing system today: route hijacks and route leaks. Route hijacks reroute internet traffic to an unintended destination, while route leaks propagate routing information to an unintended audience. Both types of incidents can be accidental as well as malicious.
Preventing route hijacks and route leaks requires considerable coordination in the internet community, a concept that fundamentally goes against the BGP’s design tenets of distributed action and autonomous operations. A key characteristic of BGP is that any network can potentially announce reachability for any IP addresses to the entire world. That means that any network can potentially have a detrimental effect on the global reachability of any internet destination.
Fortunately, there is a solution already receiving considerable deployment momentum, the Resource Public Key Infrastructure. RPKI provides an internet number resource certification infrastructure, analogous to the traditional PKI for websites. RPKI enables number resource allocation authorities and networks to specify Route Origin Authorizations that are cryptographically verifiable. ROAs can then be used by relying parties to confirm the routing information shared with them is from the authorized origin.
RPKI is standards-based and appears to be gaining traction in improving BGP security. But it also brings new challenges.
Specifically, RPKI creates new external and third-party dependencies that, as adoption continues, ultimately replace the traditionally autonomous operation of the routing system with a more centralized model. If too tightly coupled to the routing system, these dependencies may impact the robustness and resilience of the internet itself. Also, because RPKI relies on DNS and DNS depends on the routing system, network operators need to be careful not to introduce tightly coupled circular dependencies.
Regional Internet Registries, the organizations responsible for top-level number resource allocation, can potentially have direct operational implications on the routing system. Unlike DNS, the global RPKI as deployed does not have a single root of trust. Instead, it has multiple trust anchors, one operated by each of the RIRs. RPKI therefore brings significant new security, stability and resiliency requirements to RIRs, updating their traditional role of simply allocating ASNs and IP addresses with new operational requirements for ensuring the availability, confidentiality, integrity, and stability of this number resource certification infrastructure.
As part of improving BGP security and encouraging adoption of RPKI, the routing community started the Mutually Agreed Norms for Routing Security initiative in 2014. Supported by the Internet Society, MANRS aims to reduce the most common routing system vulnerabilities by creating a culture of collective responsibility towards the security, stability and resiliency of the global routing system. MANRS is continuing to gain traction, guiding internet operators on what they can do to make the routing system more reliable.
Routing by rumor has served the internet well, and a decade ago it may have been ideal because it avoided systemic dependencies. However, the increasingly critical role of the internet and the evolving cyberthreat landscape require a better approach for protecting routing information and preventing route leaks and route hijacks. As network operators deploy RPKI with security, stability and resiliency, the billions of internet-connected devices that use DNS to look up IP addresses can then communicate with those resources through networks that not only share routing information with one another as they’ve traditionally done, but also do something more. They’ll make sure that the routing information they share and use is secure — and route without rumor.
The post Routing Without Rumor: Securing the Internet’s Routing System appeared first on Verisign Blog.
This article originally appeared in The Domain Name Industry Brief (Volume 18, Issue 3)
Earlier this year, the Internet Engineering Task Force’s (IETF’s) Internet Engineering Steering Group (IESG) announced that several Proposed Standards related to the Registration Data Access Protocol (RDAP), including three that I co-authored, were being promoted to the prestigious designation of Internet Standard. Initially accepted as proposed standards six years ago, RFC 7480, RFC 7481, RFC 9082 and RFC 9083 now comprise the new Standard 95. RDAP allows users to access domain registration data and could one day replace its predecessor the WHOIS protocol. RDAP is designed to address some widely recognized deficiencies in the WHOIS protocol and can help improve the registration data chain of custody.
In the discussion that follows, I’ll look back at the registry data model, given the evolution from WHOIS to the RDAP protocol, and examine how the RDAP protocol can help improve upon the more traditional, WHOIS-based registry models.
In 1998, Network Solutions was responsible for providing both consumer-facing registrar and back-end registry functions for the legacy .com, .net and .org generic top-level domains (gTLDs). Network Solutions collected information from domain name registrants, used that information to process domain name registration requests, and published both collected data and data derived from processing registration requests (such as expiration dates and status values) in a public-facing directory service known as WHOIS.
From Network Solution’s perspective as the registry, the chain of custody for domain name registration data involved only two parties: the registrant (or their agent) and Network Solutions. With the introduction of a Shared Registration System (SRS) in 1999, multiple registrars began to compete for domain name registration business by using the registry services operated by Network Solutions. The introduction of additional registrars and the separation of registry and registrar functions added parties to the chain of custody of domain name registration data. Information flowed from the registrant, to the registrar, and then to the registry, typically crossing multiple networks and jurisdictions, as depicted in Figure 1.
Over time, new gTLDs and new registries came into existence, new WHOIS services (with different output formats) were launched, and countries adopted new laws and regulations focused on protecting the personal information associated with domain name registration data. As time progressed, it became clear that WHOIS lacked several needed features, such as:
The IETF made multiple attempts to add features to WHOIS to address some of these issues, but none of them were widely adopted. A possible replacement protocol known as the Internet Registry Information Service (IRIS) was standardized in 2005, but it was not widely adopted. Something else was needed, and the IETF went back to work to produce what became known as RDAP.
RDAP was specified in a series of five IETF Proposed Standard RFC documents, including the following, all of which were published in March 2015:
Only when RDAP was standardized did we start to see broad deployment of a possible WHOIS successor by domain name registries, domain name registrars and address registries.
The broad deployment of RDAP led to RFCs 7480 and 7481 becoming Internet Standard RFCs (part of Internet Standard 95) without modification in March 2021. As operators of registration data directory services implemented and deployed RDAP, they found places in the other specifications where minor corrections and clarifications were needed without changing the protocol itself. RFC 7482 was updated to become Internet Standard RFC 9082, which was published in June 2021. RFC 7483 was updated to become Internet Standard RFC 9083, which was also published in June 2021. All were added to Standard 95. As of the writing of this article, RFC 7484 is in the process of being reviewed and updated for elevation to Internet Standard status.
Operators of registration data directory services who implemented RDAP can take advantage of key features not available in the WHOIS protocol. I’ve highlighted some of these important features in the table below.
| RDAP Feature | Benefit |
| Standard, well-understood, and widely available HTTP transport | Relatively easy to implement, deploy and operate using common web service tools, infrastructure and applications. |
| Securable via HTTPS | Helps provide confidentiality for RDAP queries and responses, reducing the amount of information that is disclosed to monitors. |
| Structured output in JavaScript Object Notation (JSON) | JSON is well-understood and tool friendly, which makes it easier for clients to parse and format responses from all servers without the need for software that’s customized for different service providers. |
| Easily extensible | Designed to support the addition of new features without breaking existing implementations. This makes it easier to address future function needs with less risk of implementation incompatibility. |
| Internationalized output, with full support for Unicode character sets | Allows implementations to provide human-readable inputs and outputs that are represented in a language appropriate to the local operating environment. |
| Referral capability, leveraging HTTP constructs | Provides information to software clients that allow the client to retrieve additional information from other RDAP servers. This can be used to hide complexity from human users. |
| Support of standardized authentication | RDAP can take full advantage of all of the client identification, authentication and authorization methods that are available to web services. This means that RDAP can be used to provide the basic framework for differentiated access to registration data based on attributes associated with the user and the user’s query. |
Verisign’s RDAP service, which was originally launched as an experimental implementation several years before gaining widespread adoption, allows users to look up records in the registry database for all registered .com, .net, .name, .cc and .tv domain names. It also supports Internationalized Domain Names (IDNs).
We at Verisign were pleased not only to see the IETF recognize the importance of RDAP by elevating it to an Internet Standard, but also that the protocol became a requirement for ICANN-accredited registrars and registries as of August 2019. Widespread implementation of the RDAP protocol makes registration data more secure, stable and resilient, and we are hopeful that the community will evolve the prescribed implementation of RDAP such that the full power of this rich protocol will be deployed.
You can learn more in the RDAP Help section of the Verisign website, and access helpful documents such as the RDAP technical implementation guide and the RDAP response profile.
The post Industry Insights: RDAP Becomes Internet Standard appeared first on Verisign Blog.
Businesses today have many options for interacting with customers online. The findings of our independent survey of online consumers suggest that websites and branded email continue to be critical components of many businesses’ online presence, essential to supporting consumer confidence and enabling effective interaction with customers.
The quantitative study, commissioned by Verisign and conducted in December 2019 and January 2020 by 451 Research, now a part of S&P Global Market Intelligence, surveyed 5,450 online consumers across key markets in North America, Latin America, Europe and Asia to help understand their sentiments on interacting with businesses online.
The survey was designed to arm service providers and registrars with an understanding of how the resources they provide to businesses can help create trust and deliver value to their customers.
Among those surveyed, approximately two-thirds (66%) agreed that a business with its own website is more credible than one without. Likewise, a majority indicated that they would expect it to be more difficult to verify the identity of (56%), find online (55%) and contact (54%) a business that does not have its own website.
Certainly, this doesn’t suggest that businesses should abandon other online channels, such as social media and search engine efforts, to focus on a website-only approach. Instead, 64% of respondents said that a business with many points of online presence is more credible than a business with few.
Still, the study suggests that other online resources should complement, rather than replace, a small business’s own website. Respondents identified a business’s own website as being one of the most popular online methods for learning about (69%) and conducting transactions with (57%) businesses. Further, 71% of respondents reported being more likely to recommend a business with a professional website.
Taken together, these findings suggest that a website can help add credibility and drive new business.
Trust is central to the relationship between a business and customers. This may be particularly true for online transactions (95% of survey respondents said they actively make purchases online), which require consumers to trust not only that the business will deliver the product or service for which they have paid, but also that it will not misuse payment or personal information.
A branded email address may be able to help, as an overwhelming number of respondents (85%) agreed that a business with a branded email address is more credible than one that uses a free email account. Respondents were more likely to have used a business’s branded email address (67%), than the telephone (56%) or social media (40%), to communicate with a business during the prior 12 months.
For a small business, failing to be perceived as credible online could mean lost business not just today, but also in the future. A website and branded email address can help businesses add credibility and more effectively engage with consumers online.
Service providers offer a variety of website-building tools, email hosting solutions, and domain name registration services that can help businesses – whether just starting or well-established – to have a website and use a branded email.
Detailed survey results are available in 451 Research’s Black & White Paper Websites, Branded Email Remain Key to SMB Internet Services.
Verisign is a global wholesale provider of some of the world’s most recognized top-level domains, including .com and .net. For website building tools and email hosting solutions, contact a registrar. You can find a registrar here.
The post Websites, Branded Email Remain Key to SMB Internet Services appeared first on Verisign Blog.
At Verisign we have a commitment to making a positive and lasting impact on the global internet community, and on the communities in which we live and work.
This commitment guided our initial efforts to help these communities respond to and recover from the effects of the COVID-19 pandemic, over a year ago. And at the end of 2020, our sense of partnership with our local communities helped shape our efforts to alleviate COVID-related food insecurity in the areas where we have our most substantial footprint. This same sense of community is reflected in our partnership with Virginia Ready, which aims to help individuals in our home State of Virginia access training and certification to pivot to new careers in the technology sector.
We also believe that our team is one of our most important assets. We particularly value the diverse origins of our people; we have colleagues from all over the world who, in turn, are closely connected to their own communities both in the United States and elsewhere. A significant proportion of our staff are of either Asian American and Pacific Islander (AAPI) or South Asian origin, and today we are pleased to announce two charitable contributions, via our Verisign Cares program, directly related to these two communities.
First, Verisign is pleased to associate ourselves with the Stand with Asian Americans initiative, launched by AAPI business leaders in response to recent and upsetting episodes of aggression toward their community. Verisign supports this initiative and the pledge for which it stands, and has made a substantial contribution to the initiative’s partner, the Asian Pacific Fund, to help uplift the AAPI community.
Second, and after consultation with our staff, we have directed significant charitable contributions to organizations helping to fight the worsening wave of COVID-19 in India. Through Direct Relief we will be helping to provide oxygen and other medical equipment to hospitals, while through GiveIndia we will be supporting families in India impacted by COVID-19.
The ‘extended Verisign family’ of our employees, and their families and their communities, means a tremendous amount to us – it is only thanks to our talented and dedicated people that we are able to continue to fulfill our mission of enabling the world to connect online with reliability and confidence, anytime, anywhere.
The post Verisign Support for AAPI Communities and COVID Relief in India appeared first on Verisign Blog.
FreshRSS 