User trust at the heart of the latest CSA Summit in Cologne

From 22 to 24 April, Cologne hosted the Certified Senders Alliance Summit on the theme of “Trust fuels the future”. The event marked the 20th anniversary of the initiative.

Corporate communications have changed dramatically over the last 20 years with the rise of social networks. For example, Instagram now has more than 2 billion monthly users, YouTube more than 2.5 billion and Facebook more than 3 billion. These platforms were all launched between 2004 and 2010. While they have become an integral part of companies’ communications plans for addressing their users, the use of email is still very high, as there are still so many uses for email: sending email campaigns, newsletters, invoices or for example order confirmations. According to Statista, the overall volume of emails increased by 4.3% in 2023 compared with the previous year, with almost 347.3 billion emails sent worldwide every day. Another fact: on average, a person receives around 121 emails a day. These figures underline that email is not about to disappear.

Gartner nevertheless points out that concerns about email security are growing, with few companies escaping security incidents, with increasingly sophisticated phishing attacks using malicious links or attachments, for example, and data losses often linked to careless behaviour or human error. With this in mind, every year CSA brings together experts from the email ecosystem to discuss best practices and solutions for improving email quality and trust. The event is organised around a series of workshops, sessions, conferences and masterclasses.

Nameshield, which sponsored the event, pointed out that there can be no email security without secure domain names, which are critical business assets, and without a robust, high-performance DNS infrastructure. Email security therefore depends on the choice of your domain name provider and the cyber-security solutions it is able to offer its customers. These include the DMARC protocol, which protects users against fraudulent messages. Customised brand extensions also known as dot brands are another way of building brand confidence in the run-up to the next round of new generic extensions scheduled for April 2026.

Contact your Nameshield consultant for more information on all our solutions.

DNS and HTTP(S) redirects – How do they work together?

In the world of websites and domain names, it is common to want to redirect the use of a domain name to another – e.g. in the address bar of a browser – to access a website. For example:

  • Redirect to
  • Redirect to

However, it is not always easy to understand how all of this works, nor how to configure these redirects. Do I have to configure redirection at DNS level? At my web server level? Both? One or the other?

The purpose of this article is to detail the distinction between DNS «redirect» and HTTP redirect, and to present how these two protocols work together.

In the rest of the article, we will not distinguish between HTTP and HTTPS (HTTP protocol secured by a certificate). Everything that is said here is valid for both.

Understanding the difference between DNS and HTTP

DNS and HTTP are two internet protocols that are both essential to the proper functioning of the web, but do not have the same purpose.

Let’s take the example of a user who wants to access He enters in the address bar of his favorite browser.

  1. Before the browser can send a request to obtain the content of the website’s home page, it must know to which IP address it must send the request. This is where DNS comes in. The browser sends a DNS query (using DNS protocol) to a resolver: «Give me the IP address associated with». It gets back an IP address ( configured on an authoritative DNS server. We’re talking about the resolution of the domain name.
  2. The browser can then send the HTTP request (using HTTP protocol) to the HTTP server (or web server) whose IP address it has just obtained: «Give me the content of the web page». In return, it receives the content of the page to display.

The DNS protocol offers types of records that allow to «redirect» one domain to another: especially the CNAME type. Although DNS “redirect” is easily referred to, the term “alias” is more appropriate. Strictly speaking, this does not redirect, but indicates that the domain we are resolving is an alias of another domain. You must then resolve this other domain to obtain the IP address you are looking for.

Let’s say we want to create a redirect from to If we configure the DNS zone of with a CNAME record of this type: CNAME, that basically means : “You want to know the IP address associated with Well, look for the one associated with and you’ll get your answer.” Another DNS query will be sent to resolve and obtain the IP address. The browser will have the IP address of the HTTP server we are interested in (the one hosting the website, but this will not change the content of the HTTP request sent by the browser: “Give me the content of the web page”.

You may notice that the HTTP request sent by the browser contains the name of the website (or host – here that you want to access. Indeed, a single server (and therefore a single IP address) can host dozens of different websites. It will only respond positively to HTTP requests containing a host for which it is configured. Knowing the IP address of the web server is not enough, one must also address an HTTP request to which it is able to respond. Sending a request to some server configured only to respond to will not work!

The HTTP protocol also offers a redirection system (here it is the appropriate term). An HTTP server can be configured to redirect one host to another. For example, if it receive HTTP requests “Give me the content of the web page”, it will answer “This resource is redirected to” Then the browser will repeat the following steps:

  1. DNS lookup of
  2. Send a request to the IP address obtained
  3. Display the web page obtained

How to make DNS and HTTP redirects work well together?

Let’s recap:

  • DNS is used to resolve a domain name to obtain an IP address.
  • HTTP requests are sent to an IP address, and contain the host of the website you want to access.
  • HTTP servers can return different contents depending on the host present in the request: a web page they host, a redirect for which they have been configured, or an error if the host is unknown to them.

So, to make a redirect work correctly (still using the same example), you must have:

  • A DNS record in the zone to associate the www host with the IP address of a web server…
  • …web server on which a redirect from to must be configured.

How Nameshield can help you

Nameshield offers an HTTP (and HTTPS) redirect service that simplifies the configuration of these redirections, which you can use from the moment Nameshield is the DNS provider of your domain to be redirected. Simply go to the technical configuration interface of your domain name, then in the tab «HTTP redirections». You can then create a new redirect on the host of your choice, specifying various parameters (such as the repercussion of directories and query parameters). Our system will then automatically:

  • Update the DNS zone to add records (A/AAAA or CNAME depending on the host) to point to the IP address of the Nameshield HTTP redirect server. In the zone configuration interface, a dedicated icon makes it easy to distinguish these automatically added records.
  • Configure a new redirect on our HTTP server (with an anycast architecture if you have a premium offer) according to the requested parameters.

Your redirect is then operational, you have nothing more to do. No changes are necessary with your web hosting provider.

If you want to change the destination of an existing HTTP redirect, you just have to modify the existing redirection from the same interface (no need to delete it and then to create a new one). No changes are expected on the DNS, since the host already points to our HTTP redirect server. Our system will modify the HTTP server configuration, and your new redirect will be effective in a few minutes.

If you have any questions about this article, please contact your customer support team.

Meet Nameshield on the it-sa from 10th to 12th October 2023 in Nuremberg, Germany

Meet Nameshield from 10th to 12th October in Nuremberg at a new edition of the it-sa, the absolutely must-attend meeting of the IT security sector!

As the “Home of IT Security“, it-sa stands for both a comprehensive range of information and networking and knowledge exchange on the topics of data protection and IT security.

The three-day programme includes talks, workshops, discussion panels, one-to-one meetings and opportunities for networking…

Meet us on site: Hall 7, Stand 7-214, in cooperation with eco, the Association of the Internet Industry.

Exchange with our team and discover our global solutions that satisfy the requirements of your DNS security. Discover our product for a high-availability of your strategic domains: “DNS Bastion“.

For more information, visit the event website:

Nameshield’s DNS Premium labelled France Cybersecurity

The digital transformation of companies creates an increasing dependence on networks.

Websites, emails, VPN, applications… these company key services must remain accessible. An interruption would be dramatic.

DNS is the access point to all these services. It translates domain names into IP addresses and routes traffic to these services. It is increasingly exposed to attacks, yet remains poorly secured due to a lack of knowledge. With the increase in threats, maintaining its DNS infrastructure is becoming more and more complex.

Securing strategic domain names by hosting them on highly secure DNS offering permanent availability, to avoid any interruption to company key services, has become a necessity.

Nameshield, certified ISO 27001 on all its registrar activities, protects companies’ critical digital services against cyber threats, and proposes a DNS Premium solution that ensures high availability of online services.

Nameshield’s DNS Premium has been labelled France Cybersecurity since 2018. This label is a guarantee for users that Nameshield’s products and services present a level of quality in cybersecurity verified by an independent jury.

Cybersecurity is at the heart of Nameshield’s DNA, through its CERT and ISO 27001 certification. In a sector dominated by American players, this label is the perfect way to highlight our sovereign solutions such as DNS Premium“, Christophe Gérard, Nameshield’s Products Director.

The Centenary of the 24 Hours of Le Mans

The Centenary of the 24 Hours of Le Mans Race

The weekend of June 10 and 11 marked the Centenary of the 24 Hours of Le Mans, the world’s biggest race in endurance car racing. During the entire week, it was possible to attend the practice sessions and numerous events organized in parallel.

The long-awaited Centenary edition lived up to all its promises. Battles in all categories, tension right through to Sunday, and 24 hours later, it was Ferrari who came out on top and won the 24 Hours of Le Mans Race 2023, a victory 58 years after the brand’s last success.

Followed by millions of people, this international event was able to rely on Nameshield’s highly secure DNS infrastructure, offering permanent high availability, for its website. Traffic peaked throughout the event, and a record number of tickets sold ensured the success of the 24 Hours of Le Mans Centenary race!

Image source :

ICANN76, Sally Costerton, the new interim president of ICANN, makes her mark

Candidate in March 2020 and then in March 2021, the city of Cancun finally had to wait until March 2023 and the end of the COVID pandemic to see a new edition of an ICANN summit in person. 2023, a very important year for the organisation. It will indeed celebrate its 25 years of existence while it is going through a risky period with an interim presidency after the resignation of its former President on 22 December 2022.

ICANN76, Sally Costerton, the new interim president of ICANN, makes her mark

Two women at the head of ICANN

Sally Costerton from the UK, who has been Vice President of Global Stakeholder Engagement (GSE) in charge of stakeholder engagement and awareness of ICANN and its mission worldwide since 2012, has been appointed interim Chief Executive Officer of ICANN following the departure of Goran Marby at the end of 2022. She is supported by Tripti Sinha who serves as ICANN’s Board Chair. Tripti is also Associate Vice President and Chief Technology Officer at the University of Maryland, in the Information Technology Division. This is the first time ICANN has had two women leaders. However, the situation echoes the creation of ICANN. As it was recalled at the opening ceremony, in 1998, when the US government gave ICANN the task of managing the DNS addressing system, a woman also held the position of Chair of the Board. This was Esther Dyson.

While leadership interims are rare at ICANN, this situation led to the organisation of a special session called “The Future of ICANN and the Next President and CEO”. A session where participants would have expected to interact with the new Board. This was not the case, as this session was like a kind of open mic without a direct interlocutor to express expectations towards the new Management of the organisation.

An interim presidency for a governance organisation also means a risky period, especially as there is no shortage of issues to address and the geopolitical context is tending towards increased fragmentation. However, although we do not know how long the interim presidency will last, Sally Costerton quickly made her mark at the start of the summit, when she declared, among other things, “I do not know everything, but I can rely on experts“. These words were reassuring and showed a pragmatic approach.

Transparency tested by experience

ICANN is a well-established organisation, as it has been holding summits for 25 years. The trend in recent years has been for the Supporting Organisations (SOs) and Advisory Committees (ACs) that make up the organisation to move towards greater transparency by opening up almost all their sessions to the participants. The most significant transformation has been in the GAC, the body representing governments, whose sessions were closed for many years before being fully open to all participants. This is an opportunity to salute the work of Manal Ismail, who after nearly six years at the head of the GAC is leaving her place to the Paraguayan Nicolas Caballero. A global tendency, therefore, of a nature to generate confidence, a key value to respond to the more and more numerous detractors of the ICANN governance mode.

But this tendency was reversed during this summit because many sessions were closed, “Closed sessions” to which even some affiliated participants could not have access neither in face-to-face nor in remote. Some of the participants were very upset and did not fail to point this out during the traditional Public Forum which usually closes the week of meetings.

Progress at a forced march?

The consensual approach, typical of ICANN, is both a strength for federating players around new obligations that are adopted, but also a weakness because it considerably slows down the progress of important work.

A striking example is the DNS abuse. Malicious use is indeed a real problem given the damage suffered by the affected Internet users. The GAC did not fail to recall this once again during a session where external experts were invited, such as a representative of the Federal Bureau of Investigation, the FBI. The latter indicated that in the United States, in 2022, more than 800,000 domain names were the subject of complaints causing losses of more than 10 billion US dollars. While the topic of DNS abuse has been a recurring theme at every ICANN summit over the years, it is clear that the consensus has shown its limits. Stakeholders in the GNSO, the generic name policy body, have never been able to agree on a way forward, whether it be a Policy Development Process or contract negotiations to revise stakeholder contracts with ICANN. After recent consultations with stakeholders, the GNSO finally decided on the second option, and the least we can say is that at ICANN76, the will was to reach a result quickly. An amendment to the registry and registrar contracts is being drafted and is expected to be presented in June and voted on by the parties concerned in October.  

The GNSO intends to build on the momentum of another contract amendment being voted on by stakeholders: an “RDAP” amendment. RDAP is an alternative protocol to Whois that provides access to domain names registration data. The outcome of the votes and thus the adoption of these contract revisions remained uncertain at the end of the ICANN summit as different thresholds of participation and favourable votes must be reached.

Partial adoption of recommendations for future rounds of new gTLDs

Another issue that some would like to see move forward more quickly is that of future rounds of new generic extensions. Indeed, the last window for applications for generic extensions dates back to January 2012. Since then, a policy development process has been conducted since 2015 to define a set of recommendations for the holding of new application windows. The Final report of this process was submitted to the ICANN Board in February 2021. In the autumn of 2021, ICANN surprised the community by announcing a scoping phase, an ODP (Operational Design Phase), which ultimately lasted until the beginning of this year. The board had not yet decided on the Final report of recommendations, a prerequisite to be able to start the implementation work of the recommendations. So the new interim president of ICANN was also very much expected on this subject.

And she quickly warned that the time was also for action on this subject: “You will see that things will be clarified” (editor’s note: on the next series of generic extensions), she declared during a session during the week. At the end of the week, at a Board meeting, 98 recommendations from the policy development process were adopted, with a further 38 put on hold as requiring further information. An implementation plan is also expected with a deadline set to 1st of August with a focus on internationalized domain names and extensions that ICANN organisation wants to focus on in future rounds and the need to clarify whether closed generic extensions will be offered.

Comments from NAMESHIELD

We can regret a return to a certain opacity in the decision making during ICANN76 where no less than 25 closed sessions were held. Nevertheless, this is perhaps where the progress made on subjects that were not progressing well came from, such as DNS abuse, a very important subject for NAMESHIELD, which offers several solutions to defend your online assets, and the holding of a forthcoming series of new generic extensions, where NAMESHIELD experts can also accompany you.

The other question was how the new interim ICANN President Sally Costerton, would handle her new role in a risky period for ICANN whose model is also increasingly challenged by States, international organisations and even technological alternatives. On this point, the new president appeared to be proactive, joining words to deeds, as on the subject of further series of new generic extensions. Sally Costerton seems to have already started to trace her way towards a full term CEO role for the organisation.

Image source : ICANN’s website

New document : 5 minutes to understand DNS cache poisoning

5 minutes to understand - Domain names - DNS cache poisoning - Nameshield

The DNS (Domain Name System) is a key service of the Internet. It is a giant, hierarchical and distributed directory that associates IP addresses with domain names that are easier to identify, remember and transmit. It is the cornerstone of the Internet, whose infrastructure has flaws by its very conception, making it an ideal target for attacks.

On one hand, the DNS service is based on the authoritative DNS, which holds the information, and on the other hand, the resolver DNS, which carries out the resolution for the web users.
The DNS cache poisoning attack targets resolver DNS.

Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, what is this DNS cache poisoning attack and how to protect against it.

New document : 5 minutes to understand the DNS resolution of domain names

5 minutes to understand - DNS resolution of domain names - Nameshield

Human beings have a very bad memory for number sequences. However, computers and servers communicate with each other by identifying themselves through an IP address, which is a sequence of numbers or a mix of numbers that is very complex to memorize and differentiate.

To help people communicate over networks, the Domain Names System (DNS) was invented. This service is a giant Internet directory, hierarchical and distributed worldwide, which associates domain names with IP addresses.

When a web user enters a domain name in his browser, it queries a DNS server which will look for the answer to this humanly understandable address, most often an IP address, leading to the right website, computer or network. This query process is called “DNS resolution“.

Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, how the DNS resolution works.

The importance of reverse DNS

Reverse DNS - Nameshield
Image source : Jonbonsilver via Pixabay

Reverse DNS is often unknown to domain name managers, especially when the names are hosted by major hosting companies. Reverse DNS allows you to resolve from an IP address to an FQDN. This is the exact opposite of the classic use of DNS, which associates domain names to IP addresses. The reverse DNS allows to answer the question: I have an IP address, what is the FQDN related to it?

Reverse DNS operates by creating a reverse DNS zone in which DNS PTR records (for Pointer Record) will be configured.

  • Classic DNS: Record A: we know the name of a site and we want to obtain its IP address…
  • Reverse DNS PTR: we know an IP address and we want to retrieve the name of the site.

The resolution system is constructed in a similar way to the classic resolution. To perform DNS resolution, the IP address to be queried is configured in the reverse zone with the suffix .arpa and points to the required destination. The principle is the same for IP v4 and v6 addresses according to the following construction:

Ex: IPv4: IN PTR

Ex: IPv6: 4080 IN PTR

This construction enables to operate a classic DNS resolution on a domain name with a “.arpa” extension.

Why is this so important?

Reverse DNS is mainly used to track the origin of a website visitor, the origin of an e-mail message, etc. It is usually not as critical as the classic DNS, visitors will reach the website even without the presence of reverse DNS for the IP of the web server or the IP of the visitor.

However, Reverse DNS is important for one particular application: the e-mail system.

Many mail servers on the Internet are configured to reject incoming mail from any IP address that does not have reverse DNS. For those who manage their own mail server, reverse DNS must exist for the IP address from which the outgoing e-mail is sent.

Regardless of the address to which the reverse DNS record of the IP address points, a reverse DNS record is expected. In case of hosting several domains on a single mail server, it is enough to configure the reverse DNS to point to the domain name considered as the main one (mail servers checking the reverse DNS recognize that it is normal to host many domains on a single IP address and that it would be impossible to list all these domains in the reverse DNS for IP). We recommend that you check the possibility of setting up reverse DNS with your DNS hosting solution.

Choosing the right TLD based on DNS performance

Comparative analysis of the famous Top Level Domains (.com, .fr…)

The crux of the war for high-visibility websites is the download time. As a natural referencing factor admitted by Google, this download time can be significantly impacted during DNS resolution. If it is necessary to rely on a first-class DNS infrastructure, the choice of the extension associated with a domain name is important. Indeed, not all registries perform equally well in terms of DNS, not to say that some have disappointing performance. The offer in terms of TLDs (nearly 1400) has greatly increased since ICANN’s New Extensions Program. Analysis to follow.

A quick look at DNS resolution time and its impact on load time

Resolving a domain such as follows several steps before you can contact the content server. The DNS resolver contacts the root DNS servers (.), then the DNS servers of the registry of the extension concerned (.net) in order to obtain the list of DNS servers responsible for the domain, and finally these DNS servers to obtain the requested response. The response obtained is certainly cached by the DNS resolver (generally managed by the Internet Service Provider), but this will not always be the case depending on the popularity of your domain.

This means that if the DNS for the top level domain (.net) is slow, it may actually delay DNS resolution for the domain itself and, in the very unlikely worst case scenario, even cause a breakdown. There’s not much you can do about this, apart from choosing the right TLD.

Comparative Analysis

Bunny CDN, a Slovenian content delivery player, conducted the following surprising analysis. Relying on their global network, they monitored DNS performance worldwide from more than 50 sites and networks.

For each TLD, their system chose a random name server published for each top-level domains and queried a random domain name. The results were grouped by region and the data recorded every 10 seconds.


They tested 42 of the most popular top-level domains and then aggregated the results into a global median average and an 85-percentile aggregation (the 15% slowest responses were not taken into account). These tests were conducted only from their network, so a more complete study would certainly be worthwhile, but they provide a good overview.

Choosing the right TLD based on DNS performance
Source : BunnyCDN

The results were quite surprising

The most surprising domains are .info and .org, which have shown really poor performance, especially in the 85 percentile range, despite their seniority and the millions of domains registered. It seems that 4 of the 6 names servers function extremely poorly, which explains the poor results.

The .net and .com have been very slightly slower than expected in Europe and North America, but otherwise offer excellent and stable performance in all regions, visible in the global median. .net and .com have much larger networks, but remain a very interesting choice for absolute maximum performance.

Less expected is the performance of the .co, .biz and .in TLDs, well ahead of the others.

Some new domains (.online, .top, .blog…), which are attractive from a marketing point of view and growing strongly, show disappointing performances…

… on the other hand, very good surprises for .live, .email, .news, managed by Donuts Inc or .club and .buzz managed by Neustar Inc, with, however, a very important decrease in performance in regions outside Europe and North America, which further aggravates the problem.

42 of the most popular TLDs among the 1400+ available have been tested. Without drawing any definitive conclusions, we can assume that many may not work much better.


Do you need to revolutionize the management of your domain name portfolio and the choice of TLDs for your most visible websites? Should you switch everything to .biz or .co immediately to increase performance?

Certainly not. First of all, DNS responses are heavily cached, especially for very popular websites, resolvers may not need to reach many top-level names servers. Then, the choice of a domain name is primarily driven by marketing imperatives (brand, geographical area, name availability) that are often far more impactful than the additional 50 milliseconds of loading time for the first page to load.

However, if you are trying to compress absolutely every last bit of performance and ensure high reliability in a system where every last millisecond counts, then you may want to think twice before choosing your domain. The differences aren’t huge, but if you’re aiming for that one-second loading time, things can add up to 200 ms in some cases.

Choosing the right TLD based on DNS performance is indeed a good thing, but probably not a cause for too much concern.