IGF 2018 - Day 1 - Salle VI - WS408 DNS Enhancements and Alternatives for the Future Internet

The following are the outputs of the real-time captioning taken during the Thirteenth Annual Meeting of the Internet Governance Forum (IGF) in Paris, France, from 12 to 14 November 2018. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the event, but should not be treated as an authoritative record. 



>> MODERATOR: Good morning to everybody.  We are starting this examination on DNS enhancements and alternatives for the future Internet, and one of the organizers of this panel, together with Chiara, and ‑‑ okay.  The motivation is the Internet has changed our lives in the last 40 years.  And what we know and the advancements.  It's a fact of our lives that ‑‑ that we interact with the space around us, so we have different understanding of our world, thanks to ‑‑ and as our world has changed, the Internet has changed also.  We have other technologies and protocols but actually one is the key services to access the Internet DNS, has not changed.  It has proved to be robust technology and solution to keep with the evolution of the Internet so far.  Now there are changes.  What has changed is not only the technical solution but the way DNS is actually managed.  As to say, we have higher number of server all over the world, but still we have the same organization in place of this management and we have collected these names.

The Internet has changed, in terms of the data being transferred all over the world.  And, you know, there are changes that are coming up with the technology, such as internet of things.  So that will change the way we use the Internet.  A few years ago, Cisco mentioned that we will have devices by 2020 and honestly it seems to be one of those things that may or may not happen.  A number have IP address and have connected to the Internet and provide information and provide serviced ‑‑ and this is going to massively change the kind of the number of devices so that we will have an IP address, possibly the number of domain and DNS, of course, is going to be considered as one of the solutions also to translate from a name to an IP address also in the case of IoT devices.

So how will this affect DNS?  The volume of devices connected to the Internet is going to change.  It could stress the infrastructure.  Is it still true that with this kind of traffic, the policies have been a key of DNS success will have to be the same.  Is it the same when I have to cache content over website or when I have to the information of an IoT device to track logistics.  There are big changes that can affect this.

Surely the IoT has been stressing DNS solution in the last few years, giving much higher power to attack DNS.  We have seen attacks starting from low tier IoT devices that have resulting in successful denial of service attacks.

So surely this is something that has led ICANN ‑‑ the organization that is managing DNS ‑‑ to make a statement on its website that DNS has now to change and, for instance, that DNSSEC, which is a proposal that has come up a few years back, but is still not widely used is necessary.

So we are speaking now also, you know, the ‑‑ within the ‑‑ in the field of those that have been managing the evolution of DNS about needed changes.  So this is exactly the reason for this panel.  There are big changes in the Internet, the traffic and the volumes and there are reasons why also the managing authorities are discussing the approach that has been taken so far by DNS.

Now, the point is how should DNS be changed.  In the meanwhile, the technology has changed.  We can think about not only evolutionary approaches, for instance software defined network, individualization, makes possible to have more evolution in our Internet nowadays.  The computing power available in our SmartPhone today is of the same amount and probably in the ‑‑ in the near future much higher that big computers that we had in the past.

So we have at hand and with low cost, very high‑powered devices that can store a lot of data.  Today we have typically high data connecting to the Internet.

Can this result into the fact that we could decide today differently the DNS evolution?  We have also have the proof of different approaches, centralized versus peer‑to‑peer.  Peer‑to‑peer has been used in Internet application.  When we speak about being sure of the integrity of the information exchanged, like blockchain that are being considered for future of Internet.  So all of these are, you know, just some initial thoughts.  We will discuss better with our speakers today what are the challenges and what are the right solution for DNS evolution.

And I'm very honored to have experts of these topics that will be part of the panel today.  We will start with professor Wang.  Then we will have Khaled Coubaa and then Ted hardy, and Jeremy Rand.

I will give the floor to the speakers, and the question I would like to ask, what are the current forecast and challenges in terms of both the DNS solution and also in terms of DNS management?  How do you address these changes, from a evolutionary or revolutionary approach.  I want to discuss the nonproblems and the ones that are not still evident but that you see based on the big changes that are in front of us for the Internet evolution.

So thanks a lot, and we'll give ten minutes to Professor Wang.  Thanks.

>> DONGBIN WANG:  I'm a scientist of China association of science and technology.


For first let's look at address resolution mechanism.  When we want to access a website, such as Wikipedia, we will look at DNS to get IP address, but assuming the result has no cache recalls to accelerate the process, the resolution process, that is to the route server.  In typical operation, the route servers do not answer directly, but respond with servers.  Wikipedia is referred to the server.  And the server goes to those referred to and it repeats the pro e sees until it receives iterative answer.  The host is named fully qualified domain.  Wikipedia.

DNS speck Knick will suffer from DDOS attack, because of its centralized resolution.  The DNS spoofing and cache poisoning bring damage to DNS.  The requester cannot get the evolution in the right figure.

Some new technology is emerging, such as blockchain.  Blockchain decentralized distributed and public digital ledger.  It can not be altered.  Without alteration of all subsequent blocks and the consensus of the network.  This allows the participants to verify and audit transactions inexpensively.  A blockchain database is managed autonomously using a peer‑to‑peer network and the distributed time stamping server.

Blockchain is presented based on blockchain, neutral roots union can be formed.  DNS information was stored in the blockchain.  It has the advantage of decentralization.  There's distributed consensus when serve the DNS service.

Thank you very much.

>> MODERATOR: Thanks a lot.  So we ‑‑ we go on with the next presentation by Khaled Koubaa.  So ‑‑

>> KHALED KOUBAA:  Thank you.  Thank you, distinguished guests and friends and colleagues from the members of the ICANN, the Internet Governance community.

First of all, I would like to thank the organizers of this workshop University of Rome Lasapienza.  It's my measure to present this.  It's a very important workshop for us on the DNS enhancement. and the future Internet.

So the workshop presentation, the organizers reminded us how much the Domain Name System is one of the crucial futures of today's Internet.  I personally would tend to confirm this statement and this is where, in fact, ICANN comes in.  Our role is to coordinate the system of unique identifiers, including the top of the DNS hierarchy.

I can bottom up multi‑stakeholder approach, makes sure that the DNS space is managed properly.  This is an important limit that we are staying and keeping ourself focused on that mission, and the responsibility.

And the ‑‑ our last ICANN public meeting in Barcelona, the board chair explained in his opening speech, the intention of the board to develop a strategic plan, that intent to propose a new vision that will guide all the ICANN work.  And the new vision said to work to champion the single open and globally interoperable Internet and to be trusted warden of its unique identifiers.

And this vision will be implemented through five big objectives.  So the first one will be to ensure the stability of the Internet unique identifier system by addressing exponentially security challenges.  The second one is to advance ICANN governance by maturing its multi‑stakeholder model, organizational processes and cross organizational collaboration.

The third objective is to enable the multilingual Internet.  And to be better served broader and more diverse user base.  The fourth one will be to strengthen the ICANN's ‑‑ the ICANN role to ‑‑ as trusted global coordinator of the Internet unique identifier, and identify the issues impacting our mission.

And finally, the fourth objective is to make sure that ICANN has financial responsibility and through adequate funding vats.

So as you can see, we made the challenges related to the Internet unique identifier systems as the top of the list of our objectives.

In regards to ‑‑ I took a few things and issues that I considered important, in the presentation, and I'm answering them, one after the other.  So in regards to the load balance, and the system efficiency, it's important to remember that with the hierarchical name space, the search must start at the top of the name space and there's no way to avoid it.  That does not imply any inefficiency, by the way, as far as load distribution goes, the design of the DNS inevitably means that servers for the higher level portions of the name space will receive a lot of queries, but those servers have been proficient accordingly.

For example, the DNS route zone is the most over provisioned zone in the entire name space with around 1,000 instances, distributed worldwide to answer queries.

And TLDs operating within the ICANN framework are having the same contractual obligation to provision adequately.  In regards to security the same over provisioning described above that addresses load concerns also applies to address concerns about the denial of services attack.  This concern may be an indirect reference to attack late in 2016, which took down a large number of valuable Internet properties but this has nothing to do with the DNS or its hierarchical structure.  This is a market concentration issue.  There would be similar concerns with blockchain or any other services.

While it's true that the majority of route servers are US‑based.  They are distributed worldwide, and as you mentioned in the map you just showed to us.

There's simply no technical argument there regarding the distribution of route services.  This is the last technical problem and it has been solved already by having a large number of routes spread around the world and the route operator organizations are participating in the ICANN processes via ISEC.  And DNS makes up a very small portion of the Internet traffic.  So the distribution of DNS servers is not what defines how the Internet traffic flows or is balanced.

Many other factors, indeed, such as routing decisions and content distribution solutions are part of what drives this distribution of Internet traffic.

And finally in regards to the challenges to the DNS posed by emerging technologies such as Internet of Things, for example, let me say that the traffic is growing whatever we do, growing all the time anyway.  So scaling over time is part of growing the DNS and this is our responsibility and we are doing it.

One could point that the hierarchy of the DNS makes it easy to scale to the IoT devices and so it would be extraordinarily difficult to achieve using other technologies.

Thank you again, and I will stay for any questions.

Thank you.

>> MODERATOR: Thanks a lot.

Then I pass the floor to Ted Hardy from IETF.

>> TED HARDY:  I have to confess I was sort of invited at the last minute and I suspect I'm either the cuckoo in the nest that got asked who has a different view than the organizers or has some concerns about the existing system.

First of all, I will remind folks that the Internet existed before the DNS.  As it happened I started my career working in the Internet at SRI International when it was the SRINIC before the DNS existed and when we distributed the mapping table as hosts.text twice a week, and we discovered the scaling problems with trying to distribute that from a centralized location pretty early.  And the work that the team did to create the DNS was actually in response to scaling properties we saw back in the '80s.  So it has been a while since we went through that transition, but it has certainly occurred before and it's not something we would rule out in the future, but it's something where we have to pay a great deal attention to what exactly we are experimenting with and what it is that we want in the result of those experiments.

As the organizers correctly pointed out, there were a very small number of organizations that originally stood up those route name servers and those represent a diversity that's really more the diversity of the 1980s than the diversity of utilization today.  As Khaled has pointed out, that diversity is not actually mapped into the actual locations of DNS services now.  There are currently 919 DNS route services as I understand it.  If you call up OCTO at ICANN, David will ship you the 921st and the 922nd and the 923rd.  It's become very plug and play.  It describes how to use any casts for DNS.  I feel a certain pride in that.  It scaled quite a bit.  At the moment we are serving about 1 million queries per second across the route name service.

Any experimentation we see has to look at what is experimenting on before it tackles such an important part of the Internet infrastructure and one piece it could be experimenting with is the name structures itself, as Dr. Wang pointed out ‑‑ excuse me, Professor Wang pointed out, there were a great number of these things that are about the data structures that use public ledger systems.  It's a data structure already used in Internet infrastructure.  But those in turn don't relate really to the data governance of those.  So it's not a data consensus protocol, the way the bit coin.

It's a public ledger system with a well‑described audit mechanism.  And if you wanted to see something similar in the DNS as an adjunct to the current distribution methods, there's really no reason not to experiment in that method but we should be concerned to understand that that doesn't mean changing the DNS to a consensus‑based protocol.

A consensus‑based protocol, which determined which changes went into the DNS by the consensus of all the participants would be a very different change and, indeed for many people who have concerns that what they serve is well understood by the public to be their content or their service, it would be probably a change that they would not support.

Clearly if you are part of the banking system or part of the government system, having a consensus determine the name to IP mapping of why you are service, would be problematic.

So we need to understand that when and where we pull in the consensus aspects of ‑‑ of these protocols is something that experimentation and indeed research is needed around.  Our colleagues at the Internet research task force in the distributed Internet infrastructure research group are working on that right now.  With the folks from Stellar an a number of other groups like that from Etheria.  So it's something that research and experimentation is needed but it's something where we have to really have clear goals for what those experiments will be talking to us about.

Are they talking to us about the data structures or the mechanisms by which the name to IP address mappings are governed?  And I think that's a point that as we go through this panel, I encourage people to think about as two separate pieces of experimentation.

Lastly, I want to point out that there's actually a lot of change that's occurred in the DNS recently, in part because of the issues around pervasive public surveillance.  We introduced a number of changes to the protocols that serve the DNS.  The DNS is now available over detail DNS, and transport layer, over HTTP and there's experimentation using revolver lists which uses web packaging to take the kinds of exchanges which have crossed over HTTP and distribute them in other methods.  They can be over HTTP, over a black chain and over any peer‑to‑peer protocol you care to.

What is critical about those is once again looking at the core methods of DNS and saying do we get the same guarantees if we distribute them across other protocols?  And because the DNS has an object security model in DNSSEC, provided you are doing validation, and you have the records for DNSSEC, you can actually distribute it anyway you like, and still get the same cryptographic assurance is what the DNS zone maintainer put into the DNS.

So there's a great deal of experimentation that we can do in distribution, provided we link it to the cryptographic assurances without changing the overall system.

Lastly, I will point out that the ITF has had a number of folks come to us over time to look at very, very different name to address mapping systems.  The folks involved with onion routing, the tour project have come and requested a special purpose name from the ITF, in order to allow the tore nodes to have a way of including them in URI strings and other parts of the upper layer identifier system.  That went through and what happened with that is the IAB said there needs to be a place in the current name space to allow people who are experimenting with the different name to address mapping systems to do their work and as a result, we invited people who are looking at that kind of mapping to request name space allocations under.arpa, which the IAB controls.

We would allow people doing novel resolution mechanisms to have a place to look at how their resolution mechanism fits into the overall system.  And I think that's really where we are looking at this.  We would love for this experimentation to continue, but we want the result to be a single name space at the end of the day.  Because the value of that single name space helps drive the Internet as remaining a single system.  And that's a key value that the IAB has championed for a very long time, that the value of the Internet is higher and better realized for the users if it's ultimately a single system.

So as we go through these experiments, we really hope that those are key goals of those who are experimenting with it.

Thank you very much.

>> MODERATOR: Thanks a lot for your presentation.  And then I give the floor to Jing Ma.  We have loaded your slides.  One second.

Yes, if you can, use some sign, we will ‑‑

>> Yes.

>> Okay.  Microphone working?  So we're here at Internet Governance Forum 2018, where the slogan is:  Internet of trust.  And I think this is unintentionally a very apt slogan because in the DNS, we need to trust a lot of third parties.

For example, there's registrars, the TLD registries, recursive revolvers and authoritative name servers and, of course the ICANN route but I don't think an Internet of trust is actually what we should one.  While those trusted third parties usually behave correctly, there is a risk that they can make a mistake or that a subset of them might in the future, possibly just the future become malicious.  And if that had a happens there could be censorship or hijacking as aI result.

As the legendary ‑‑ trusted third parties are security holes.

So you may be wondering why do I think trusted third parties are so concerning.  I think what it comes down to is that humans inherently behave non‑deterministically.  In particular that means that even if a system has ground rules that are supposed to be completely invilable, and if they are enforced by humans they will inevitably be inconsistently enforced and human behavior as we go further into the future becomes more deterministic.

So namecoin is an experiment to find out is it possible that we could build something that is superficially similar to the DNS, but with as little involvement by humans as possible?  The intent here is that we could therefore create a DNS‑like system that behaves more deterministically than the DNS, thereby removing some trusted third parties and hopefully eliminating some of those security holes that Nick Sabo used.

Name coin used ‑‑ we would like to work with them to recognize this.  Under the hood, Namecoin is pretty much identical to the bit coin name base with small modifications specifically the coins in Namecoin can represent domain names intending of funding currency units.  As a result of that design, censoring or hijacking a name coin domain name is roughly equivalent to freezing or stealing bit coins which is very difficult, unless they have the cryptographic private key.  I should note that my presentation is assuming that you believe bit coin is reasonably secure.  Maybe some of don't think that bit coin is reasonably secure and that's okay.

If that's the case, name coin may not be for you.

So what are some real world use cases where namecoin's deterministic behavior can improve security compared to the DNS.  Let's say you are trying to buy or sell a name.  In the DNS, this would usually involve some counterparty risk or an agent who becomes a trusted third party.  In namecoin this is handed quite differently.  They jointly construct a transaction that atomically pays the seller and transfers the name of the buyer and this eliminates the counterparty risk without requiring the services of an escrow agent.

As a further extension of this concept, you can also create what we call a non‑interactive buy or sell offers and as an example of this, let's say Alice creates a sell offer for whoever sells me 100 name coins and they have the sell offer and she's willing to transfer it in exchange for 100 namecoins.  And Alice can post the sign/sell offer pretty much wherever you like on a forum or pay spin, take your pick.

Now Bob sees this offer and wants to buy example.bit.  Bob can complete the offer by signing that sell offer with a private key that owns 100 namecoins and by doing this, the offer is actually now a completely valid namecoin transaction and Bob can broadcast that to the namecoin peer‑to‑peer network without contacting Alice about it first.

Alice gets paid her 100 namecoins and Bob receives example.bit.  It's fully atomic, and we don't need the services of a trusted ago and this works for both buy and sell offers.

Switching gears from buying and selling names to actually using names, another use case is the TLS public key infrastructure which HTTPS encryption relies on.  The certificate authority system relied on by HTTPS is somewhat concerning.  I know there's someone with a let's encrypt sticker.  I hope I'm not offending you.

The thing is there are too many non‑deterministic humans involved as certificate authorities and these trusted third parties form security holes.  Chiara, they can use a speck called Dane, which listed TLS certificates in the DNS, but there are some political concerns there.  Some people, whether for good reason or not, are nervous about the possibility of abuse of power or maybe accidental security breeches by the DNS route or TLD or registrars.  And namecoin can provide similar to what Dane provides but without that particular political issue and without trading one trusted third party for another.

You might have heard the term Dark Web before.  It's often a term that's massively misused by the media and so I will define it before I use it.  Dark Web, it uses software besides a standard browser to view them.

A major benefit to Dark Web sites allows them to know elevator in web technology without getting the web browsers on board first.  A significant subset of Dark Web systems use cryptography to offer security advantages compared to regular websites.  For example, tor, zeronet improves resilience to web hosting server downtown and CGNIF.

Now while namecoin qualifies a Dark Web.  It's also a naming system for the three that I mentioned.  Noes systems may want to have DNS‑like functionality.  So namecoin is a fairly natural fit there.

For those use cases like TLS and Dark Web protocols, it probably goes without taking that very bad things would happen if a name coin names private keys get compromised this is also theoretically true for DNSSEC but because DNSSEC is not widely used for those use cases, this is unchartered territory.  It requires multiple signatures in different keys.  In the world of DNS this can theoretically be done in threshold signatures but I'm not aware of such a feature actually being deployed in the DNS, in any meaningful capacity.

In namecoin, a solution to this is that a name can be owned by a threshold amount of different private keys and this can be a useful protection against a single compromised key.  As an example, a board of directors could each have a private key and updating the name might require a super majority of the board and you can independently control the number of signatures requiredden athe number of total public keys in that pool.

Namecoin also allows some very flexible policies to be built, which don't have any direct analog in the DNS for users who are very concerned about private key compromise.  As an example of one such policy, let's say Alice owns a name coin name and she's using it to list her HTTPS certificate and she wants to limit the risk of stolen private keys.  She constructions a policy of this.  She can track Trent and she can update her name, including the HTTPS certificate if Trent signs her update and Trent promises he will only do this after verifying Alice's identity using two factor authentication of some type.

Trent, meanwhile, presigns a specific transaction that can revocal is' primary HTTPS certificate and he gives that transaction to Alice.  That means that Alice can then revoke that certificate later by signing the transaction herself, even if at that point, Trent has gone offline or maliciously refuses to sign.

Similarly, Trent presigns another transaction that transfers the name to Alice's sole control, but which is only valid a certain number of days in the future.  And Trent gives this transaction to Alice as well.  This means that Alice can then recover her name, after that many days, even if by that point Trent has gone out of business or has lost his private key.

Some of the key features here are that Trent cannot transfer or update Alice's name without Alice's significant and Alice can verify that the presigned transactions she got from Trent are authentic and she's protected from Ma yourless or accidental problems from Trent before she applies this policy to her name and these policies are fairly flexible and they are enforced to the exact same levels that ECD levels are.

Something to note here, even though namecoin is decentralized that doesn't mean that registrars go away.  Something in namecoin that might be called a registrar might look a lot like Trent in this scenario.  But namecoin does imply that registrars have a lot less ability to harm their customers than they do in the DNS whether that as accidental or malicious harm.  It is conceivable that this might lead to decreased security budgets for registrars and I think that would be an interesting thing to study in the future.

So thanks for inviting me.  Hopefully I have covered a very brief overview of namecoin's security‑related features.  I will be happy to answer any additional questions in the Q&A portion of this workshop.

Thank you.

>> MODERATOR: Thanks a lot.  Now I give the floor to Francesco Pirro.  Just one second and we load your presentation.

>> FRANCESCO PIRRO: Good morning to everybody.  My name is Francesco Pirro and I work for the digital Italy Internet.

I'm pleased to be invited here and thanks to the organization for these decisions in the AgId.  You are probably asking why we are interested in the Internet DNS enhancement.  You are right.  This curiosity was born when someone describes to me in the function, in the ICANN function.

I essentially ask why it's not impossible to involve a self‑managed system to manage their register names process in the blockchain age.  I don't remember the exact answer, but the sense of this was that it would have not been possible.  I am a curious man and I have explored this problem a little bit more deeper.  Realizing Italian organization that managed this issue.

Moreover, when my analysis became deeper my curiosity grew.  I discovered that there were complex situation of accountability of this issue in Italy and not only in Italy.  And in the meanwhile, my curiosity grew more.  I asked different Italian experts to analyze with me this problem without any incentive to go into more details on it matter and I have to thank Chiara for organizing this panel.

DNS, in fact, as said, Khaled said before, is organized for the structure with the route server with 13 IP address corresponding to 900 server protocols.  They have the correct operation of Internet traffic routing of route server.

Clearly, the DNS as hierarchy structure for reasons of efficiency and scalable, but in my opinion, a contradiction in a network that was born and based on a peer‑to‑peer principles in.

My opinion, DNS hierarchy does not create only a technical philosophic contribution but also in organization structure.  Allowing the adoption of business models that helps only some players who can operate in a system without competition since they have the exclusive control of the level of the hierarchy as seeing them the registry operators and they have registers.

These organizations are also nonprofit and have revenue up to 10 times.  I respect their spending.

Some questions, is it possible to think about real competitive system to register and the registrar role?  Is it possible to imagine a self‑managed system supervised by only ICANN, for instance, based on bit coin and for registered accreditation?  ICANN is nonprofit corporation, and how they are funds and revenues are managed?  In this fund management there's something about the research for an alternative system to the actual hierarchy structure.

As we know, DNS as the hierarchy structure offered DNS service for 5 billion server devices.  Today there are 327 million of register name.  DNS is actually used in 20, 25 milliseconds and it's perfect for 5 million device but it could not be show for trillions of device in the network.

5 billionth of device and trillions of device in 2025.  After the IoT wave, the Internet grow will be impressive.  It follows an exponential trend.

The problem and so I have read that there are a lot of scientific studied that demonstrate that DNS traffic towers top level domain is useless but not necessary, but the vast majority of this device continues to produce these, either on politic device or for DNS bot net, mallware or similar situation.

In the next future, this problem will grow more and more.  And we have to consider that this will happen even to ‑‑ even to the network topology of IoT should be resolved in a local zone.  Imagine connecting an energy device or security camera or others.  They should generate a lot of traffic that should be resolved in the local zone and not our top level domain, but in the correct use of IoT network should attract top level domain as experience can make believe in it.

This doesn't happen, unfortunately today and probably it will not happen tomorrow with IoT.

Probably it will be not a problem now, because the actual hierarchy structure will be scalable, and Internet will not change, but I think that is reasonable begin to evaluate these extraordinary growth.

The problem is that I have not seen anything about the research funding in this particular topic, but essentially for the network operations.  DNS, hierarchy structure, that was peer‑to‑peer architecture is possible.

I hope that this situation change soon at least in Europe.  Probably the hierarchy architecture, at least two problems.  Traffic management, with explosion of IoT and potential security risk because the hierarchy server are easy target for malicious attacks.

One of these example, was made on December 2016.  It was a company that controlled much of the world DNS, and the huge portion of this Internet.  It go down with Twitter, NetFlix, CNN and so on.

And also for this reason, several approach have been started that provide a reasonable structure based, for example on peer‑to‑peer networks that the user distributed a stable or blockchain.

Hybrid DNS and blockchain‑based solutions make me think we have to evaluate possible alternatives to a hierarchy structure and also the creator said it.

To conclude my speech, let me therefore come back on the point that I have tried before, about the explosion of IoT.  Another idea, in fact to avoid the idea of extraordinary traffic increase, from the explosion of IoT and malicious use of this, could be to separate these two architecture of different topology.  It distinguishes IoT from usual web traffic.  I imagine a different name system, instead of only one Domain Name System.

As I said before, it is important to evaluate the importance of change to avoid the potential risk of IoT and security problem deriving also from this.

I don't know now if in the next year there will be a specialized cloud for every IoT sector managed by the main five registry operators or by telco providers or complainant DNS as DNS for IoT or another DNS, but peer‑to‑peer like bit coin or hybrid system or SD card, the solution, but surely something shall change and whatever will be this new infrastructure it shall be compliant with actual DNS system and shall operate better, either for the traffic manager, either for the potential security problem.

We have started an alternative solution for DNS‑based on a mix of solution among blockchain and system like torrent.  We are going to submit in the next weeks a technical proposal to ITF to discuss it.

I finish my speech with a famous sentence on Italian actor, begin new path worries us but after every step, we understand how it would have been dangerous to remain firm, Roberto Benigni.

Thank you.

>> MODERATOR: Thanks a lot.  We now open the floor to questions.  Also from the panelists.

>> TED HARDY:  There were two things that were mentioned earlier.  One our colleague from namecoin talked about the utilization of multiple keys to create trust in a change.  That's actually how the root key signing ceremony goes right now.  Four times a year.

>> Yes, the root cell does that.

>> TED HARDY:  It's quite easy to extend that into any ‑‑ it's a well‑known set of processes.  And there are models built into the DNS that allow you to do that.

The second point goes to the point that was being made here.  I feel like there are three different topics one is how the registry system works and might be considered a set of pro toe Kohls that replaced that mark or EPP and its protocols.  The difference is how you might manage the DNS named distribution system differently, and a third is really around what experimentation in very, very different kinds of names might exist.  Right?

So I think those are three different topics we heard today.  I think for the mark system, having that market system turnaround and say, now we are going to publish this into the standard DNS, and the distribution of names from an alternative market system, would be one type of experimentation that wouldn't actually require you to have different names.  It just would require you to have the people who are participating in that alternative market agree to use that market for the exchange of names instead of the existing set of systems.

So I think that is, in some sense, part of the naming infrastructure but not part of the DNS, where I think the point that you were making was like, how do we deal with the new scale?  How do we deal with the fact that there are these ‑‑ as Khaled pointed out ‑‑ market leaders who brought so many names into their DNS distribution infrastructure, that the collapse of one of these infrastructure suppliers has an impact on names that were not expected to be impacted by a particular attack or a particular change.

And on that point, there's actually a very fundamental pieces of the DNS protocol system that people don't use because it's ‑‑ it's easier not to and one of them is that you don't have to have a single name server and you don't have to have that name server when you have multiples all controlled about the same organization.  It's very easy in the way the DNS is constructioned to have the administrator of the name to declare different technical organizations as responsible for its distribution and if any one of those organizations is up, the DNS is resilient to an attack on the others.

So it's really built with this in mind, and some people were like, my ‑‑ my current vendor is big enough, I don't have to worry about that.  I'm just going to rely on them and they discovered that maybe that's not a good idea.  Maybe they actually need to use that part of the DNS.

Similarly, there are a whole bunch of pieces to the DNS that are designed to cause you not to reach the root with what you have is a local name.  Once you can use the root server itself.  You can put it on a loop back and avoid those ever traversing your network.  Two, there's a whole bunch of systems around negative caching that Warren Kumary and the members of the DNS Working Group have put out saying hey, if this is not a name being with he can tell you right now that this is not a name and you can aggressively cache the fact you got a no from it and you don't ask the root.

So I think that the current system from the point of view of how we deal with DNS distribution and how we deal with market integration with DNS distribution has the points of integration already there.

What we don't see and where real experimentation would be useful is people who are playing with different kinds of names.  So there's experimentation that's going on in the name dating networking group and other places where what they are actually talking about are hashes of content.  And fitting those into the existing system is more of a routing problem than a DNS problem at the moment.  It's can conceived of that way and understanding how those fit is a very different kind of experimentation that we definitely need and I think it would be very valuable for us to consider how each one of these different pieces of engineering or research is distinguished from each other, so that when we go forward and do the research that this panel calls for, we understand what pieces of the system we're updating or approaching.

Thank you.


>> FRANCESCO PIRRO: Let me say that I like Roberto Benigni a lot, he's my personal favorite.  I think the bit coin, applying it to the DNS, we have considered three points that we need to raise on how to apply bit coin.  The first one is a technical point, and for us, the blockchain have scaling problem, both in term of number of transactions per second and the energy consume but the security model is still not very well understood.

Yes, there's grit everywhere, but this does not mean that the blockchain cannot be corrupted.  There have been a number of high‑profile cases in the last months of that.

The second point will be on the operational and trust model.  The blockchain relies on network ever minors.  Because of the huge electricity consumption, minors tend to be concentrated in a small number of places where electricity is cheap.  This is too many root servers and operators in the US.  Also there's a trust issue here.  Blockchain users would trust the miners to dot right thing and expect that crypto to prevent things and that could be vulnerable for the service attacks.  We can show we can operate blockchain ‑‑ so who to go when something goes wrong with the blockchain?

The problem is the global economy worldwide.  If you change the DNS to a blockchain governance system, to who will go when something go wrong?

And the model is clear.  You can go to ICANN for the case of the gTLDs and in the case of blockchain, there's no one to ‑‑ to ‑‑ this is a major governance issue and this is an important issue as well.

>> MODERATOR: Francesco.

>> FRANCESCO PIRRO: Another day, another idea for Ted, hmm?

Another solution to explore is based on the adoption of blockchain at the DNS in every mobile device that can be saved in cloud.  There are 327 million will registered names of one kilobites each one and it's about 300, 400, gigbites.  It's time to read the other about nano seconds and the average access time in traditional hierarchy DNS structure is about 20, 20 millisecond.

And this time shall increase for the explosion of IoT and the adoption of DNSSEC to avoid the problem, to the DNS both net malicious attack.  The growth of registered names as a logarithmic trend, instead it increase exponentially.

In 2018, now there are already available two tetrabytes of capacity.  And its growth is exponential.  In a few months, it will reach 100 gigabytes per second.

>> MODERATOR: Jeremy.

>> JEREMY RAND: Yes.  So a few different things were mentioned by fellow panelists that I would like to comment on.  The gentleman from IETF said that there's sort of a potential separation.  Consensus layer, which would be for things like determining what the ‑‑ what ‑‑ what data a domain name points to, compared to actually looking it up and things like that.

I think that is true and, in fact, the ‑‑ the way that namecoin is designed to work, ideally is it would probably interoperate with the DNS.  So, for example, when you install namecoin today, it basically sets up an authoritative name server on hole coast, which supplies a dot bit zone, and this does interoperate with the DNS and so a lot of DNS infrastructure can be used in combination with name coin.  You can even delegate from name coin to an authoritative.  Namecoin is not real intended to replace DNS in any way and there are separate layers here.

Regarding how well blockchain scales, yeah, namecoin and blockchain stuff in general does not scale well.  That's absolutely a fair criticism.  Honestly, namecoin doesn't scale quite as badly as one might assume it would, but it scales far worse than the DNS and so this is definitely something to keep in mind as the number of domain names increases in the DNS, that presents bigger and bigger challenges to using something like a blockchain with it.

Regarding the question of how much damage malicious miners or compromised miners can do to a blockchain, I think this is actually something where there's a lot of misconceptions.  In general, the miners have a lot less power to do mischief than one would assume.  Miners are only trusted for the purpose of determining the order of transactions.  Miners did not have the capacity to arbitrarily insert invalid transactions into the blockchain.

In the case of blockchain, that means that they have the ability to ‑‑ if they have a majority of hash power, malicious miners could prevent updates to names from being confirmed into the blockchain.

And if they can do that for a period of around eight months straight, without being stopped first, then they could force a name to expire and then they could reregister it themselves.

This obviously would be a relatively damaging attack, but it is not anywhere near as damaging as you think economists perception is.  Some people think that miners can rewrite history.  That's not how it's works.  Miners are not trusted that extent.

The question is who do you go to in something goes wrong with blockchain.  This is definitely a tradeoff that exists.  And this doesn't new to blockchain technology and it's not specific to naming itself.  For example, with ‑‑ with strong encryption, if you encrypt your hard disk on your computer and then you lose the pass phrase, well, there's no one you can go to, to recover the stuff on your computer.  I hope you made a backup.

In is a tradeoff.  On one side of the tradeoff, there's people who want to have someone to go to when something goes wrong who can fix things and on the other hand, people want a system that behaves more determine in any eventically, that doesn't have trusted third parties and is more secure against the attacks that trusted third parties can do, and, yeah, you kind of can't have it both ways.  You have to choose one or the other.  Some people, I think, like namecoin's model better.  And other people like DNS's model better and that's okay.  The systems can absolutely coexist.  And we definitely don't claim that namecoin's design choice here is inherently better.

So, yeah.

>> MODERATOR: Thank you.  Any comment by Professor Wang?  No?  Okay.

Is there any question from online audience?  So far no.  If you want to ask a question, you can do it.  There is ‑‑ Mrs. Ma is checking your questions right now.  So any other comment?  Questions from the audience?  Please.

>> AUDIENCE MEMBER: I'm with Verisign.  Mr. Rand, this is for you.  Your presentation was predicated on the lack of trust.  And your first two use cases are supportive of what we call in the DNS domainers in buying and selling domains.  I'm curious what types of right protections you have in place in name coin or blockchain that have to do with the geographic names for nation states.

>> MODERATOR: Jeremy, please, if you can answer.

>> JEREMY RAND: Yeah, so that's absolutely a good point.  And unfortunately, there is no good solution for a decentralized system to recognize things like trademarks.  This is unfortunate.  It does mean that squatting can be more of a concern in the name coin world, than it is in the DNS world.  The inherent issue here is that in order to determine whether a name is violating a trademark or is in any other way violating someone's rights, this requires some kind of centralized entity to maintain a trademark database and if that centralized entity is compromised or malicious, they would have the ability to censor arbitrary names.

And namecoin makes the tradeoff that we want to make censorship as difficult as possible and we have to make the tradeoff that yeah, we don't have any mechanism for taking down domain names that are infringing on a trademark.

That said, there are some alternative approaches.  There are well established system like fish tank that notifies users, hey this website is believed to be Phish scam.  Systems like that can work to some extent to mitigate trademark infringement but yeah, they are definitely not going as well suited like the DNS.  Yes, this is definitely a problem but I don't think there are at the good solutions so we have to decide what tradeoff do we want to make?  This is another reason why namecoin and the DNS should coexist because some users care more about making a censorship as difficult as possible and enforcing free speech and other users want to have that protection from trademark infringement for sites they visit that only like a centralized system like the DNS can provide.  It's up to the user what system meets their users.

Yeah, we don't have a good solution but that's I think how the laws of math work out.

>> MODERATOR: Thanks a lot.

>> AUDIENCE MEMBER: Mr. Koubaa, I had a question for you.  It seemed like you slightly changed the wording of ICANN's, management of unique identifiers to include the DNS hierarchy, to include the DNS hierarchy is something new aren't heard before.  Does that mean that ICANN or the ICANN board is taking a look at bringing in identifier to include block blockchain.  So it's not to have any new things.  So it's just to mention that identifiers including DNS.

>> I just want to point out that they do a whole bunch of identifiers as well as the DNS work that they do, the ITF works with IANA to register those.  That's just another piece of this puzzle.

>> MODERATOR: Please.

>> JEREMY RAND: Also, I want to clarify one thing that I neglected to say in my previous comment about squatting.  I am strongly against squatting.  I don't think that squatting is ethical.  I think that there are legitimate reasons why someone would want to sell a domain name to someone else.  I think it's in everyone's best interest to do that without getting scammed which is the motive for the atomic name for currency trading that I mentioned.

That said, I definitely hate squatters.  I hope no one here got the impression that I think squatting is ethical in any way.  Yeah, I wanted to make that clear.

>> MODERATOR: Any other questions?  I think we have time for another question.  Is there from the audience?

Any other comment from panelists?  Okay.  So I thank ‑‑ I would like to thank all the panelists today.  I think we have heard, you know, different views and also got a lot information about what's going on in IETF and the thinking in ICANN and new ideas that things ‑‑ this discussion is ongoing and there's space for experimentation, within IETF.  Thanks to Ted for pointing it out.  I think it could go in the direction of stimulate, of our thinking and experimentation soon.  So I want to thank all the panelists for this interesting panel.

Thanks a lot.


Thanks.  So we close the panel.

>> And thank you for organizing.