 ICACT20220132 Slide.01
[Big Slide]
[YouTube] |
Chrome  Click!! |
 |
My name is Yong Jin from Tokyo Institute of Technology, Japan, today, I am going to talk about acceleration of a client based DNSSEC validation system in parallel with two full-service resolvers". |
| ICACT20220132 Slide.02
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Here is the outline of my presentation. |
| ICACT20220132 Slide.03
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
As you know well, IP addresses are necessary for the communication in the Internet
but they are not appropriate for memorizing. Therefore domain names are mainly
used instead for Internet users and service providers. Accordingly, domain name
system is necessary for the translation between IP addresses and domain names.
|
| ICACT20220132 Slide.04
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
In domain name system, there are two types of DNS servers, authoritative DNS server
and cache DNS server. Authoritative DNS server runs domain name management with
authorization while cache DNS server provides name resolution service for the end
clients. As shown in the figure, the client sends DNS query to the cache DNS server
and the cache DNS server performs domain name resolution by querying each
authoritative DNS server. Finally, the cache DNS server replies the answer back to the
client.
|
| ICACT20220132 Slide.05
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Although cache DNS server can improve domain name resolution performance, it has
a well-known security concern named cache poisoning attack. The attacker can make
cache DNS server add fake DNS resource records which make the client access malicious
web sites. A normal cache DNS server has no function to verify the integrity of DNS
responses.
|
| ICACT20220132 Slide.06
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
As an effective solution for cache poisoning attack, DNSSEC has been proposed and
standardized. DNSSEC uses public cryptography and guarantees the integrity of DNS
responses between cache DNS server and authoritative DNS server. As shown in this
figure, the authoritative DNS server signs the zone file using its secret key and replies
the corresponding DNS resource records with the signature and the public key to the
cache DNS server. Then, the cache DNS server verifies the signature using the public
key and check the integrity of the DNS response. Although DNSSEC can avoid cache
poisoning attacks but it also cause some issues in terms of workload increase on
cache DNS server and domain name resolution failure in case of DNSSEC validation
failure.
|
| ICACT20220132 Slide.07
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
In order to solve the existing issues of DNSSEC we have proposed a client based
DNSSEC validation system.In the system, the DNSSEC validation will be conducted
on each end client and the DNSSEC validation will be turned off. This system can
solve some existing issues in DNSSEC such as the workload increase of cache
DNS server and domain name resolution failure due to DNSSEC misconfiguration.
In addition, the system also provides a function that displays a pop-up message to
the users in case of DNSSEC validation failure and timeout.
|
| ICACT20220132 Slide.08
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Although the previous work can solve some existing issues in DNSSEC, it also causes
another issue. In the previous system, each end client conducts DNSSEC validation and
the results only store in the internal cache. It means that the successfully validated DNS
resources records cannot be shared with other end clients. Accordingly, the system may
cause low name resolution performance on end clients.
|
| ICACT20220132 Slide.09
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
The objective of this paper is to accelerate name resolution on end clients by improving
the cache hit rate.In addition to use the client based DNSSEC validation system, a method
to share the successfully validated DNS resource records will be added. Specifically, the
DNSSEC validation will be enabled on each end client and the each end client also uses
the successfully validated DNS resource records achieved from external cache DNS
server.
|
| ICACT20220132 Slide.10
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
The first approach we considered is to share successfully DNSSEC validated DNS
resources records using a DNS sharing server. Each end client updates the successfully
validated DNS resource records to the DNS sharing server using dynamic DNS update.
Then each end client queries the DNS sharing server first in the domain name resolution
and if there is no cache hit the end client will continue to query the external cache DNS
server. However, this approach has a critical flaw that the malicious users or infected
clients may add fake DNS resource records to the DNS sharing server. Moreover,
although TSIG will be used in the dynamic DNS update, when the TSIG key is stolen it
can be used maliciously. |
| ICACT20220132 Slide.11
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
The second approach is that in addition to add a DNS sharing server, the DNS sharing
server also performs DNSSEC validation before caching the updated DNS resource
records. However, it needs complicated configuration on the DNS sharing server and
the DNS sharing server needs to communicate with the external DNS servers in the
Internet thus it may cause security concerns.
|
| ICACT20220132 Slide.12
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
Considering the possible issues in the two approaches, in this paper, we propose a new
method by using two cache DNS server in parallel. In the proposed system, we assume
that DNSSEC validation feature is enabled on each end client by installing the client
based DNSSEC validation system. In the proposed system, the first try of name resolution
for a domain name will be validated on each end client and the same request will also be
sent to an external cache DNS server with DNSSEC enabled in parallel. Since the DNSSEC
validation on the cache DNS server will take time thus the results of the end client will be
used while the result of the cache DNS server will be cached on its own. From the second
time, the response from the external cache DNS server will be fast since the successfully
validated DNS resource records have been cached. Consequently, the results from the
external cache DNS server will be used. |
| ICACT20220132 Slide.13
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This figure shows the procedure of domain name resolution in the proposed system.
The client sends DNS query to DNSSEC enabled cache DNS server and DNSSEC
disabled cache DNS server simultaneously. Since the overload of DNSSEC enabled
cache DNS Server is high, thus the validation in the DNSSEC enabled cache DNS Server
will be slow.On the other hand, the response from the DNSSEC disabled cache DNS
Server will be fast and it need validation on the client.
|
| ICACT20220132 Slide.14
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
From the second time of DNS query for the same domain name, since the validation
finished DNS resource records have been cached in the DNSSEC enabled cache DNS
server, thus the response from the DNSSEC enabled cache DNS Server will be fast.
Accordingly, the response from the DNSSEC disabled cache DNS Server will need validation on the client, thus the response will be late and dropped.
|
| ICACT20220132 Slide.15
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
We implemented 2 types of prototype systems using Perl language. The first type was
implemented using fork function. In this type, when the system receives a DNS query,
a child process will be created and the child process conducts the normal query and
the query on the previously proposed client based DNSSEC validation system. The
second type was implemented by creating a specific name resolution process. In this
type, the specific process conducts normal DNS query and the previously proposed
client based DNSSEC validation system works as usual. As a result, two processes
reply DNS responses individually. We evaluated the two types of prototype systems
and compared them with the conventional DNS name resolution method.
|
| ICACT20220132 Slide.16
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
We used two physical servers and several virtual machines in the prototype system.
We used Perl language and Perl modules in the proposed system as shown in this slide. |
| ICACT20220132 Slide.17
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This slide shows the evaluation results on client1. We measured the latency of name
resolution for domain name google.com.The first try on the client based DNSSSEC
validation took 13.7 milliseconds and from the second try it took 46.4 milliseconds.
In the proposed system, when we used the fork function it took 60.2 milliseconds
and when we used the specific process it took 48.6 milliseconds.
|
| ICACT20220132 Slide.18
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This slide shows the evaluation results on client2.When there is no cache hit on the client
and the cache DNS server, the name resolution for google.com took 106 milliseconds and
17.6 milliseconds when there was cache on the client. When we used the proposed system,
in case of using fork function it took about 33.6 milliseconds and 24.4 milliseconds when
we used the specific process. From the results, we can see that the overhead of using fork
function causes 10 milliseconds more latency.
|
| ICACT20220132 Slide.19
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This slide shows the evaluation results comparing for types of DNS queries in client1.
From the results, we can see that when we used the specific process for the parallel
query the name resolution latency is the smallest. While the latency of the previously
proposed client based DNSSEC validation system was the biggest.
|
| ICACT20220132 Slide.20
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
This slide shows the evaluation results comparing the four types of DNS queries on
client2. From the results, we can see the the latency of the previously proposed client
based DNSSEC validation system was the biggest one as well.Then the latency of the
case when there is cache on the client is the smallest. Moreover, when there is no cache
on the client the latency of using the specific process in the parallel query is the
smallest one.
|
| ICACT20220132 Slide.21
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
As a summary, in this paper, we proposed an acceleration method of a client based
DNSSEC validation system in parallel with two full service resolvers. The first try of
domain name resolution took about 100-150 milliseconds and the results will be
cached on the end client if the validation successes. From the second try on the same
client the domain name resolution took 20-40 milliseconds. If we use the parallel query
to a cache DNS server, the first try with DNSSEC took 10 seconds if the validation was
performed from the root DNS server. Therefore, in the proposed system, the first try for
a domain name resolution will use the client based DNSSEC validation system.
On the other hand, the first try on other clients for the same domain name resolution,
it took 25-60 milliseconds. Accordingly, in the proposed system, the acceleration of the
first try of name resolution on other clients has been realized.
|
| ICACT20220132 Slide.22
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
The future work includes four tasks.
The first one is performance improvement for the specific process.
The second one is to conditionally stop the DNSSEC validation on end clients when
it receives responses from the DNSSEC enabled cache DNS server.
The third one is to improve the performance of client DNSSEC validation system with
changing the server configuration and packet process procedure.
The last one is to consider the topology of cache DNS servers in the proposed system.
|
| ICACT20220132 Slide.23
[Big Slide]
[YouTube] |
Chrome Click!! |
 |
That‘s all for my presentation. Thank you. |
