1 INFOCOMMUNICATIONS1> REPLACE THIS LINE JOURNAL WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATIONMethodology NUMBER (DOUBLECLICK for DNS Cache PoisoningHERE TO EDIT)Vulnerability < Analysis of DNS64 Implementations
Methodology for DNS Cache Poisoning INFOCOMMUNICATIONS JOURNAL 6 Methodology for DNS Cache Poisoning MethodologyVulnerability for AnalysisDNS Cache of DNS64 Poisoning So the conclusion for a real noisy environment is that the [8] W. D. Zhong, C. Chen, H. Yang and P. Du, “Performance Analysis of Vulnerability Analysis of DNS64 longer the codes the better the Gold code sets are, but under a Angle Diversity Multi-Element Receiver in Indoor Multi-Cell Visible Light Communication Systems”, International Conference on VulnerabilityImplementations Analysis of DNS64 certain code length the performance of Gold codes and OOCs Transparent Optical Networks (ICTON), 2017. may be similar. Implementations [9] S. Shawky, M.A. El-Shimy, Z. A. El-Sahn, M. R. M. Rizk and M. H. Implementations Aly, “Improved VLC-based Indoor Positioning System Using a G. Lencse, and Y. Kadobayashi, VII. CONCLUSION Regression Approach with Conventional RSS Techniques”, International Wireless Communications and Mobile Computing G.G. Lencse, Lencse, and and Y. Y. Kadobayashi, Kadobayashi ,Member, IEEE In this paper the VLC related CDM problems are Conference (IWCMC), pp. 904-909, June 2017. discussed, focusing on the asynchronous mode CDM which is more suitable for a simple VLC system. The description of the [10] S. Yang, E. Jeong, D. Kim, H. Kim, Y. Son, and S. Han, “Indoor years or even decades. On the one hand, IPv6 transition three-dimensional location estimation based on LED visible light most common code set types, the unipolar OOCs and bipolar yearstechnologies or even are decades. important On solutions the one hand, for several IPv6 trans differentition communication”, Electronics Letters, vol. 49, no. 1, pp. 54–56, technologiesproblems, which are arise important from solutionsthe incompatibility for several of I diPv4fferent and PN codes, showed the benefits, disadvantages and January 2013. possibilities of these codes. Obtaining information about a problems,IPv6: they whichcan enable arise communication from the incompatibility in various scen of IPv4arios and[2]. [11] S. Jung, C. Choi, S. Heo, S. Lee, and C. Park, “Received Signal CDM channel quality is not as easy as measuring RSS on a IPv6:However, they oncan the enable other communication hand, they also involvein various a hig scenh numberarios [2]. of Strength Ratio Based Optical Wireless Indoor Localization Using single RF signal. It was showed that the most common quality Light Emitting Diodes for Illumination”, IEEE International However,security issueson the other [3]. Wehand, have they also surveyed involve 26 a hig IPv6h number transition of Conference on Consumer Electronics (ICCE), pp. 63–64, January securitytechnologies, issues and [3]. prioritized We have them surveyed in order to 26 be IPv6 able to trans analyzeition indicator measure, the crest factor, may be misleading in some 2013. technologies,the security vulnerabilities and prioritized of them the mostin order important to be able ones to analyzefirst [2]. cases. A possible solution is proposed for this problem, introducing two novel advanced quality indicator (AQI) [12] M. Mukherjee, "Wireless Communication – Moving from RF to theDNS64 security [4] vulnerabilities and stateful NATof the [5] most were important classified ones as first having [2]. measures. Computing these new measures along with the crest Optical," International Conference on Computing for Sustainable DNS64utmost importance,[4] and stateful because NAT they [5] weretogether classified provide as th heaving only Global Development (INDIACom), pp. 788-795, 2016. factor gives a better approximation to the CDM channel utmostsolution importance, for a communication because theyscenario, together which provide is very important the only quality. With AQI1 the noise immunity of a CDM [13] S. De Lausnay, L. De Strycker, J-P. Goemaere, N. Stevens, B. solutionnow because for a communicationof the exhaustion scenario, of the public which IPv4 is ver ady dressimportant pool, transmission using Gold codes and OOCs are compared, in Nauwelaers, “Optical CDMA Codes for an Indoor Localization nownamely, because they of enable the exhaustion IPv6only of clientsthe public to IPv4 communicat addresse pool, with System using VLC”, 3rd International Workshop on Optical Wireless function of the code length. These AQIs, for example, may Communications (IWOW), pp. 50–54, September 2014. namely,IPv4only they servers. enable IPv6only clients to communicate with improve the precision of a channel quality based VLC CDM IPv4onlyWe have servers. also developed a methodology for the identification [14] R. Gold, “Optimal Binary Sequences for Spread Spectrum indoor positioning system, and allows more reliable practical ofWe potential have also security developed issues a methodology of different for the IPv6 identi tranficationsition Multiplexing”, IEEE Transactions on Information Theory, vol. 13, comparison between various code sets. no. 4, pp. 619–621, October 1967. oftechnologies potential [6]. security Ref. [3] issues follows of the different STRIDE IPv6appro ach, tran sitionwhich
technologiesis a general software [6]. Ref. security [3] follows solution the STRIDE and it uses appro the ach,DFD which (Data ACKNOWLEDGMENT isFlow a general Diagram) software model security of the solution systems and to facilitate it uses the th DFDe discovery (Data The authors would like to thank Dr. Kari Kärkkäinen from Flowof various Diagram) threats. model We of havethe systems found to this facilitate approach the usediscoveryful and the University of Oulu, Finland for the freely downloadable Gábor Szabó was born in Győr, Hungary, ofamended various the threats. method We in [6], have where found we this have approach also shown use fulthat andit is bipolar pseudo-noise code bank, which was a great help for 1990. He received his M. Sc. degree from amendednecessary the to methodexamine in the[6], mostwhere important we have alsoimplementat shown thations it isof the CDM simulations. the Budapest University of Technology and necessarythe given to IPv6examine transition the most technologies, important implementat whether theionsy areof Economics in 2015. His research interests thesusceptible given IPv6to the transitionvarious threats technologies, that were discov whetherered the byy using are REFERENCES include optoelectronics and visible light susceptiblethe STRIDE to the approach. various Wethreats have that pointed were discov out thatered DNS64 by using is communication. thetheoretically STRIDE susceptible approach. Weto have pointed out that [7], DNS64 and now is [1] B. M. Masini, A. Bazzi and A. Zanella, "Vehicular Visible Light theoreticallythe important susceptible practical to question is, whether [7], its and different now Networks with Full Duplex Communications," IEEE International theimplementations important practical are actually question susceptible is, whether to its DNS di fferent cache Conference on Models and Technologies for Intelligent Transportation Systems (MT-ITS), pp. 98-103, 2017. implementationspoisoning or not. are actually susceptible to DNS cache Eszter Udvary was born in Budapest, [2] S. Randel, F. Breyer, S. C. Lee, and J. W. Walewski, “Advanced Hungary. She received her Ph. D. degree in I. INTRODUCTION poisoningThe purpose or not. of this paper is to develop a simple and efficient Modulation Schemes for Short-Range Optical Communications”, 2009 from Budapest University of I. INTRODUCTION methodologyThe purpose for of DNSthis paper cache is poisoning to develop vulnerability a simple an danalysis efficient of IEEE Journal of Selected Topics in Quantum Electronics, vol. 16, no. EVERAL [1] were developed methodologyDNS64 implementations. for DNS cache This poisoning paper is vulnerability based on our a nalysisworkshop of 5, pp. 1280–1289, 2010. Technology and Economics. Her research SEVERAL to support the transition from IPv4 to [1]IPv6, were which developed we are interests include microwave circuits, fiber DNS64paper [8],implementations. in which we This have paper presented is based our on testbed our w orkshop and our [3] A. Street, P. Stavrinou, D. O’brien, and D. Edwards, “Indoor optical Scurrently to support faced the with, transition and which from is IPv4 expected to IPv6, to lastwhich for weseveral are papermethod [8], for in Transaction which we have ID prediction presented attack our testbed as well a nd as our our wireless systems – a review”, Optical and Quantum Electronics, vol. optics and optoelectronics. currently faced with, and which is expected to last for several 29, no. 3, pp. 349–378, 1997. methodresults for for some Transaction specific ID DNS64 prediction implementations. attack as well No asw our we Submitted: December 28, 2017. This work was supported by the resultsgive a more for some detailed specific introduction DNS64 to implementations. cache poisoning Noincludingw we [4] T. Komine and M. Nakagawa, “Integrated system of white LED International Exchange Program of the National Institute of Information and visible-light communication and power-line communication”, IEEE Submitted: December 28, 2017. This work was supported by the giveits further a more two detailed components introduction (source to port cache number poisonin predg iction,including and Communications Technology (NICT), Japan. Transactions on Consumer Electronics, vol. 49, no. 1, pp. 71–79, International Exchange Program of the National Institute of Information and itsthe further birthday two paradox components based (source attack), port and number also design prediction, and carry and G. Lencse was with the Laboratory of Cyber Resilience, Nara Institute of 2003. Communications Technology (NICT), Japan. theout birthdaytheir testing paradox methods. based Besides attack), the and DNS64 also design implem andentations carry ScienceG. Lencse and Technology, was with the 89165 Laboratory Takayama, of Cyber Ikoma, Resilien Nara,ce, 630 Nara0192 Institute Japan. Heof [5] S. Rajagopal, R. D. Roberts, and S.-K. Lim, “IEEE 802.15.7 visible Scienceis permanently and Technology, with the Széchenyi 89165 Takayama, István University Ikoma, Nar, Győr,a, 630 H01929026, Japan. Hungary. He outincluded their testing in our workshopmethods. Besidespaper, now the weDNS64 also includeimplem Unbound,entations light communication: modulation schemes and dimming support”, is(email: permanently [email protected]) with the Széchenyi István University, Győr, H9026, Hungary. includedbecause init showedour workshop much betterpaper, performance now we also thaninclude BIND Unbound, [9]. IEEE Communications Magazine, vol. 50, no. 3, pp. 72–82, 2012. (email:Y. Kadobayashi, [email protected]) is with the Laboratory of Cyber Resilience, Nara Institute becauseThe remainderit showed much of this better paper performance is organized than asBIND follows [9].. In of Y.Science Kadobayashi, and Technology, is with the 89165 Laboratory Takayama, of Cyber Ikoma, Res Nara,ilience, 630 Nara0192 Institute Japan. [6] M. Kavehrad, “Broadband Room Service by Light”, Scientific (email: youki[email protected]). sectionThe remainderII, we examine, of this why paper DNS iscache organized poisoning as followsis so crucial. In American, vol. 297, no. 1, pp. 82–87, 2007. of Science and Technology, 89165 Takayama, Ikoma, Nara, 6300192 Japan. (email: youki[email protected]). section II, we examine, why DNS cache poisoning is so crucial [7] T. Do, J. Hwang, and M. Yoo, “TDoA Based Indoor Visible Light Positioning System”, Fifth International Conference on Ubiquitous and Future Networks (ICUFN), 2013.
DOI: 10.36244/ICJ.2018.2.3
JUNE 2018 • VOLUME X • NUMBER 2 13 INFOCOMMUNICATIONS JOURNAL Methodology for DNS Cache Poisoning Vulnerability Analysis2 of DNS64 Implementations 33 33 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >> REPLACE REPLACE THISTHIS LINE WITH YOURYOUR PAPERPAPER IDENTIFICATION IDENTIFICATION NUMBER NUMBER (DOUBLECLICK (DOUBLECLICK HERE HERE TO TO EDIT) EDIT) < < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >3 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < concerning the DNS64 technology and we also elaborate the 3. The response comes from the same network address to > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATIONBIND NUMBER did not address(DOUBLECLICK the issue properly HERE TO until EDIT) the < C ERT BINDBIND did did not not address address the the issue issue properly properly until until the the C ERT CERT attack model of DNS cache poisoning. In section III, we survey which the question was sent. notificationBIND did in not 2008 address [17], the which issue was properly triggered until by the D CanERT notificationnotification in in 2008 2008 [17], [17], which which was was triggered triggered by by D an D an the available test tools for DNS cache poisoning analysis and 4. The response comes in on the same network address, Kaminsky,BINDnotification did whonot in address invented 2008 the[17], a more issue which powerful properly was untilcachetriggered the poison C byERTing D an Kaminsky,Kaminsky, who who invented invented a amore more powerful powerful cache cache poison poisoninging point out that they are not suitable for our purposes. In section including port number, from which the question was method.notificationKaminsky, His in whoattack 2008 invented is [17],built upona which more two waspowerful ideas: triggered it cache bypa bysses poison D theaning method.method. His His attack attack is is built built upon upon two two ideas: ideas: it bypait bypassessses the the IV, we design and implement a testbed for security analysis of sent. protectionKaminsky,method. Hisof who the attack inventedTTL isby built using a more upon different powerful two random ideas: cache itnam bypa poisones ssesfroming the protectionprotection of of the the TTL TTL by by using using different different random random nam names esfrom from DNS64 implementations. In section V, we select the DNS64 In general, the first response matching these four conditions method.theprotection attacked His of attackdomain, the TTL is and built by goesusing upon one different two hierarchy ideas: random it levelbypa nam sses higher:es the from thethe attacked attacked domain, domain, and and goes goes one one hierarchy hierarchy level level higher: higher: implementations to be tested and also present their setup. In is accepted.” (from section 3 of [13]) protectioninsteadthe attacked of tryingof the domain, toTTL insert by and ausing forged goes different “A” one record hierarchyrandom into namthe level cachees from higher: of insteadinstead of of trying trying to to insert insert a forgeda forged “A” “A” record record int into theo the cache cache of of sections VI, VII, and VIII, we design and carry out different Condition 1 gives a very important protection against theinstead attacked attacked of trying DNS domain, server,to insert and it ahijacks goes forged one the “A” hierarchywhole record attac int levelkedo the zone h igher:cache by of thethe attacked attacked DNS DNS server, server, it ithijacks hijacks the the whole whole attac attackedked zone zone by by tests for the possible components of the DNS cache poisoning spoofed answers by setting up a time limit. This is insteadincludingthe attacked of trying the DNS IP to address insertserver, a of forgedit ahijacks DNS “A” the server record whole controlled int attaco theked cache by zone the of by includingincluding the the IP IP address address of of a aDNS DNS server server controlled controlled by by the the vulnerability, namely, we test Transaction ID and source port equal to the round trip time between the given DNS server and attackertheincluding attacked as theanDNS IP IP server, address address it ofhijacks of a a DNS DNS the serverwhole server attac for controlled theked azonettacked by by the attackerattacker as as an an IP IP address address of of a aDNS DNS server server for for the the attacked attacked predictability, as well as whether the DNS64 implementations the authoritative DNS server plus the response time of the domainincludingattacker into theas an an IP Authority IP address address record of aof DNS of a DNSa forged server server answer controlled for for the a by query attacked the domaindomain into into an an Authority Authority record record of ofa forgeda forged answer answer for for a query a query send out multiple equivalent queries simultaneously, which authoritative DNS server. (The latter may be increased by the forattackerdomain a random asinto an name an IP Authority from address the ofrecordattacked a DNS of zone a serverforged (to trick foranswer the the bailiwick aforttacked a query forfor a arandom random name name from from the the attacked attacked zone zone (to (to trick trick the the bailiwick bailiwick would give an opportunity for an attack based on the birthday attacker by a DoS attack against the authoritative DNS server.) rule),domainfor a seerandom into [18] an forname Authority an infrom depth recordthe and attacked of wellillustrate a forged zone (toanswer dtrick description for the a bailiwick query of rule),rule), see see [18] [18] for for an an in in depth depth and and wellillustrate wellillustrated descriptiond description of of paradox. In section IX, we summarize and discuss our results, In its calculations, the RFC uses 100ms as a typical value for theforrule), aattack. random see [18] name for from an in the depth attacked and wellillustrate zone (to trick dthe description bailiwick of the length of this time interval. Of course, an attacker may therule),the attack. attack. see [18] for an in depth and wellillustrated description of as well as we make suggestions for the elimination of the Fig. 1. Sample Transaction ID randomness testing results of the DNSOARC theThen attack. the alert was taken seriously, and patches were Fig. 1. Sample Transaction ID randomness testing results of the DNSOARC ThenThen the the alert alert was was taken taken seriously, seriously, and and patches patches wer were e uncovered vulnerabilities. Section X concludes our paper. attempt to initiate the opening of this time window at any time Fig. 1. Sample TransactionDNS ID entropy randomness testing testing tool. [20] results of the DNSOARC preparedthe attack.Then for the all alert those was major taken DNS seriously,implementations and patches that were wer e Fig. 1. Sample TransactionDNS ID entropy randomness testing testing tool.tool. [20][20] results of the DNSOARC preparedpreparedThen thefor for all alertall those those was major major taken DNS DNS seriously, implementations implementations and patches th atth werewerat weree by sending a request for an arbitrarily chosen domain name. Fig. 1. Sample TransactionDNS ID entropy randomness testing testing tool. [20] results of the DNSOARC stillprepared vulnerable. for all Also those vulnerability major DNS testing implementations tools were prepared that were DNS entropy testing tool. [20] stillstill vulnerable. vulnerable. Also Also vulnerability vulnerability testing testing tools tools were were prepared prepared II. CACHE POISONING VULNERABILITY OF DNS64 However, if a domain name is already cached, it is usually preparedand released. for all those major DNS implementations that were andandstill released. released.vulnerable. Also vulnerability testing tools were prepared protected, until its TTL expires. stillA vulnerable.contemporary Also web vulnerability based Transaction testing tools ID and were source prepared port The trustworthy operation of the DNS service is a very 3 andA contemporaryreleased. web based Transaction ID and source port Condition 2 significantly hardens the task of the attacker: the randomnessand Areleased. contemporary tester by web DNSOARC based Transaction is still available ID and [1 source9]. It isport important precondition for a secure Internet. The ultimate > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < randomnessA contemporary tester by web DNSOARC based Transaction is still available ID and [1 source9]. It isport attacker has to guess the for a successful attack. documentedrandomnessA contemporary andtester highlyweb by DNSOARCbased suggested Transaction byis still [20]. ID available and Although source [1 9].port the It is mitigation for DNS cache poisoning, as well as for all other documentedrandomness andtester highly by DNSOARC suggested byis still [20]. available Although [19]. the It is To support guessing, the attacker may send DNS resolution demonstrationrandomnessdocumented tester screen and by highly atDNSOARC the documentation suggested is still by availabledoes [20]. not Althoughseem [19]. toIt beis the tampering type attacks against DNS, is DNSSEC [10]. BIND did not address the issue properly until the CERT demonstrationdocumented screen and highly at the documentation suggested by does [20]. not Althoughseem to be the requests to the DNS server for any domain names, including documentedsodemonstration bad, see Fig. and screen1, highlyour atexperience the suggested documentation was by rather [20]. does poor. Although not When seem twe heto be However, concerning the cache poisoning vulnerability of notification in 2008 [17], which was triggered by Dan sodemonstration bad, see Fig. screen1, our atexperience the documentation was rather does poor. not When seem we to be domain names, the authoritative DNS servers of which is under demonstrationtriedso bad, it out, see amongFig. screen 1, others, ourat the experience documentation we received was the ratherdoes results not poor. seem shown When to be in we DNS64 servers we cannot rely on DNSSEC for two reasons. Kaminsky, who invented a more powerful cache poisoning triedso bad, it out, see amongFig. 1, others,our experience we received was therather results poor. shown When in we the control of the attacker, thus the attacker may observe an soFig.tried bad, 2. it Wesee out, Fig. contend among 1, our that others, experience it is we not received was enough rather the to poor. resultstest When on ly shown fivewe in First of all, its deployment rate is still very low. (As of 2016, it method. His attack is built upon two ideas: it bypasses the Fig.tried 2. it We out, contend among that others, it is we not received enough the to resultstest on ly shown five in arbitrarily long sequence of the Transaction IDs generated by triedTransactionFig. it2. out, We IDs. among contend But others,we that do not we it ishave received not an enough opportunity the results to test to shown tune only the in five was 1.7% among the Alexa top 1 million web servers [11].) The protection of the TTL by using different random names from TransactionFig. 2. We IDs. contend But we that do not it ishave not an enough opportunity to test to tune only the five the attacked DNS server. Therefore, DNS servers must use hard Fig.tests.Transaction 2. We contend IDs. But that we itdo isnot not have enough an opportunity to test on toly tune five the other reason is DNS64 specific. The task of a DNS64 server is the attacked domain, and goes one hierarchy level higher: tests.Transaction IDs. But we do not have an opportunity to tune the to predict (cryptographic) random number generators to prevent Transactiontests.Another webbased IDs. But we testing do not tool have is anmentioned opportunity in the to tuneICANN the to synthesize an [12] for the instead of trying to insert a forged “A” record into the cache of tests.Another webbased testing tool is mentioned in the ICANN the attacker from being able to predict the Transaction IDs. presentationtests.Another webbased of Kim Davies testing [21], tool butis mentioned the tool isin the no moreICANN domain names that do not have a AAAA record (IPv6 address). 15 the attacked DNS server, it hijacks the whole attacked zone by presentation of Kim Davies [21], but the tool is no more Thus, on average, a number of 2 trials are necessary for a presentationAnotherAnother webbased webbased of Kim testing Daviestesting tool tool [21], is ismentioned butmentioned the toolin inthe isthe ICANN no ICANN more However, this a forged address from the DNSSEC point of available at the URL mentioned on slide 33 of the presentation: successful guess for the 16 bit long Transaction ID (within the including the IP address of a DNS server controlled by the availablepresentationpresentation at the of of URL Kim Kim mentioned Davies Davies [21], on [21], slide but but 33 the of the toolthe tool p isresentation: isno no more more Fig. 2. Our Transaction ID randomness test result produced by the DNS http://recursive.iana.org/.available at the URL mentioned on slide 33 of the presentation: view. Thus, a and DNS client has to attacker as an IP addressFig. 2. Our of Transaction a DNS server ID randomness for the test a ttackedresult produced by the DNS http://recursive.iana.org/.available at the URL mentioned on slide 33 of the presentation: given time period of about 100ms). OARC DNS entropy testing tool. availablehttp://recursive.iana.org/.And there at the is URL another mentioned problem on with slide these 33 of webbasedthe presentation: tools: discard it. The best possible mode of operation is, when a domain into an AuthorityFig. 2. recordOur Transaction of a OARCforged ID randomnessDNS answer entropy for test testing a result query tool. produced by the DNS And there is another problem with these webbased tools: Condition 3 further hardens the task of the attacker, but not Fig.Fig. 2. 2. Our Our TransactionTransaction ID randomness testtest resultresult pproducedroduced by by the the DNS DNS http://recursive.iana.org/.http://recursive.iana.org/. security aware client asks the DNS64 server to perform the OARC DNS entropy testing tool. theyAnd require there that is the another DNS server problem is configured with these in webbased a live system. tools: very significantly. There may be a few authoritative DNS for a random name from the attacked OARCzone (to DNS trick entropy the bailiwicktestingtesting tool.tool. theyAndAnd require there there that is is anotherthe another DNS problem server problem is with configured with these these webbased in webbased a live system. tools: tools: validation, see section 3 of [4]. In this case, the client has to rule), see [18] for an in depth and wellillustrated description of theyWe require rather decidedthat the DNS to build server a is configured, that is, in ana live isolated system. servers for a domain, the IP address of which are known for the theytheyWe require require rather that decidedthat the the DNS DNS to buildserver server ais isconfigured configured, that in is, ain live ana live isolatedsystem. system. trust in the DNS64 server. (And of course, tampering may which requires randomized source port number selection. environment,We rather where decided we to can build check a whether, that the is, examine an isolatedd attacker, and the DNS server may use them in a round robin the attack. which requires randomized source port number selection. environment,WeWe rather rather decided where decided we to to build can build check a a whether, that, that is, the is, an examine an isolated isolatedd happen while the packet travels from the DNS64 server to the RFC 5452 [13] describes another form of attack, which is DNS64environment, implementations where we can indeed check have whether the the presumed examine d manner.Fig. 1. Sample The Transactionattacker needs ID randomness to spoof testing exactly results the of therig DNSht one.OARC As Then the alertwhich wasRFC requires taken5452 [13] seriously,randomized describes and source another patches port form wernumber eof attack, select whiion.ch is DNS64environment,environment, implementations where where we we can canindeed check check whether have whether the the the presumedexamine examined d client.) DNS entropy testing tool. [20] prepared for all thosewhichbasedwhich major requiresonrequires the DNS birthday randomizedrandomized implementations paradox. source If the portth atattacker number werenumber may select select achieveion.ion. that vulnerabilitiesDNS64 implementations by using any kind indeed of tests havewith any the parameters presumed their number is usually small, this condition contributes only basedRFC on 5452 the birthday[13] describes paradox. another If the attackerform of may attack, achieve whi chthat is DNS64vulnerabilitiesDNS64 implementations implementations by using any kind indeed indeed of tests have havewith theany the parameters presumed presumed Thus for protecting our DNS64 servers from DNS cache theRFCRFC DNS 54525452 server [13][13] sends describes out another formform ofof attack,attack, whiwhi, thatchch is is wevulnerabilities consider necessary. by using any kind of tests with any parameters with a small multiplication factor. As for the spoofing itself, still vulnerable. Alsobasedthe vulnerabilityDNS on the server birthday sendstesting paradox. out tools were If the prepared attacker may achieve, that that is vulnerabilitieswevulnerabilities consider necessary. by by using using any any kind kind of oftests tests with with any any parameters parameters poisoning, we need to rely on the guidelines laid down in RFC and released. basedqueriesbased onon with thethe birthdayidenticalbirthday paradox.QNAME, If QTYPE, the attackerattacker and mayQCLASSmay achieve achieve fie thatlds, that we consider necessary. there are some countermeasures against source IP address thequeries DNS with server identical sends QNAME,out QTYPE, and QCLASS, fiethatlds, is wewe consider consider necessary. necessary. 5452 [13]. Before addressing them, we need to clarify the attack A contemporarythethe web DNSDNS based serverserver Transaction(a newsendssends query out ID is and sent source while anotherport one still, , that thatwaits is is IV. TESTBED DESIGN AND IMPLEMENTATION spoofing, such as reverse path checking by routers or firewalls. queries with identical (a new query QNAME, is sent QTYPE, while another and QCLASS one still fiewaitslds, IV. TESTBED DESIGN AND IMPLEMENTATION model, that is, the conditions of a DNS cache poisoning attack. randomness testerqueriesforqueries by anDNSOARC answer) withwith identicalidentical then is the still QNAME, forged available replies QTYPE, [1 9].of theIt and and isattac QCLASSQCLASSker may fiematch fields,lds, IV. TESTBED DESIGN AND IMPLEMENTATION However, we may not rely on this optional protection: we for an answer) (a then new the query forged is sentreplies while of the another attacker one may still match waits IV.IV. TESTBEDTESTBED D ESIGNDESIGN AND AND IMPLEMENTATION IMPLEMENTATION We always consider , which means that the any of them, (a(awhich newnew querysignificantlyquery is sent easeswhilewhile theanotheranother attack. oneone For still still further waits waits suppose that it is not switched on, or the attacker is able to send documented andfor any highly an of answer) them, suggested whichthen the bysignificantly forged [20]. replies Although eases of the the attacattack. ker For may further match Although we intended to design a testbed for the security attacker may not intercept the DNS requests from the attacked fordetails,for an an answer) answer) please thenreferthen thetheto theforged CERT replies vulnerability ofof thethe attacattac notkerkere [15].may may match match Although we intended to design a testbed for the security the forged replies from the “right” direction. demonstration screenanydetails, atof thethem, please documentation which refer tosignificantly the does CERT not vulnerability seemeases to the be attack. note [15]. For further analysis of DNS64 server implementations, we made our DNS server to the authoritative DNS server. The attacker may so bad, see Fig. 1,anyany ourTo ofof experience sum them,them, up whichwhichthe wasessence significantly rather of poor.the above easeseasesWhen conditions,thethe we attack. attack. ForweFor n furthereedfurther to analysisAlthough of DNS64 we intended server to implementations, design a testbed we for made the se ocurityur Condition 4 has two contributions. The attacked DNS server details,To sum please up therefer essence to the CERTof the abovevulnerability conditions, note we[15]. need to considerationsAlthoughAlthough we wewith intended intended a broader to to design mindset, design a testbedaso testbed that the for for testbed the the se curity semaycurity send DNS requests (for any domain name) and forged replies to details,checkdetails, whether pleaseplease refer referthe analyzed to the CERT DNS64 vulnerability server implementat notnotee [15]. [15].ions use considerationsanalysis of DNS64with a broader server mindset, implementations, so that the testbed we made may o ur may have more than one network interfaces (or more than one tried it out, amongcheck To others, sum whether weup the received the essence analyzed the of resultsDNS64 the above shownserver conditions, implementat in weions need use to analysisalsoanalysis be used of of DNS64for DNS64 the security server server implementations,analysis implementations, of other IPv we we 6 madetransition made our o ur the attacked DNS server. hardToTo to sumsum predict upup thethe random essence numbers of the abovefor both conditions,conditions, Transaction wewe IDsn needeed and to to alsoconsiderations be used for withthe security a broader analysis mindset, of otherso that IPv the6 transitiontestbed may IP addresses may be assigned to the same interface), but this Fig. 2. We contendcheckhard that towhether predict it is notthe random analyzed enough numbers toDNS64 test for on server bothly five Transaction implementat IDsions and use technologies,considerationsconsiderations especially with with a abroader broaderNAT64. mindset, mindset, so sothat that the the testbed testbed may may Now, we first quote the most important conditions from RFC Transaction IDs. Butcheckchecksource we whether whether doport not numbers have thethe analyzed analyzedan andopportunity they DNS64 do notto serverserver tune send the implementat implementatmultiple equivalentionsions use use technologies,also be used especially for the security NAT64. analysis of other IPv6 transition number is limited, thus it may be only a small factor. The hardsource to portpredict numbers random and numbers they do fornot bothsend Transactionmultiple equivalent IDs and alsoalsoIn be general,be used used for for the the the requirements security security analysis analysis for suchof ofother other a testbedIPv IPv6 transition6 usutransitionally 5452, when a DNS server (called as “resolver” in the text) may tests. hardquerieshard toto predictconcurrently.predict randomrandom numbers for bothboth TransactionTransaction IDs IDs and and technologies,In general, theespecially requirements NAT64. for such a testbed usually can be another significant factor, if the DNS server sourcequeries port concurrently. numbers and they do not send multiple equivalent includetechnologies,technologies, the following: especially especially NAT64. NAT64. accept information from a DNS reply packet, and then interpret Another webbasedsourcesource testing portport numberstoolnumbers is mentioned and they indo the notnot ICANN sendsend multiplemultiple eequivalentquivalent includeIn general,the following: the requirements for such a testbed usually uses different, hard to predict source port numbers for sending queries concurrently. In1.In general,isolated general, theenvironment, the requirements requirements where for attacks for such such may a testbeda be testbed performe usu usuallyd ally them for our situation. presentation of Kimqueries DaviesIII. concurrently. T [21],OOLS butFOR C theACHE tool P OISONING is no more VULNERABILITY include1. isolated the following: environment, where attacks may be performed queries III.concurrently. TOOLS FOR CACHE POISONING VULNERABILITY include2. ease the following:of use out its every single request. As port numbers from 0 to 1023 include2. ease the of following: use “DNS data is to be accepted by a resolver if and only if: available at the URL mentioned on slide 33 ofT theESTING presentation: 1.3.1. isolatedlowisolated cost. environment, environment, where where attacks attacks may may be beperforme performed d cannot be used, the entropy is somewhat less than 16 bits. III.III. TTOOLSOOLS FOR CACHETESTING POISONING VVULNERABILITYULNERABILITY 3.1. lowisolated cost. environment, where attacks may be performed 1. The question section of the reply packet is equivalent to Fig. 2. Our Transaction ID randomness test result produced by the DNS http://recursive.iana.org/.III. TOOLS FOR CACHE POISONING VULNERABILITY A2.2. testbed easeease offor of use theuse security analysis of different IPv6 transition We note that NAT (more exactly: NAPT) devices may Although Daniel J. BernsteinTESTING already disclosed the 2. ease of use that of a question packet currently waiting for a OARC DNS entropy testing tool. And there is anotherAlthough problem Daniel with these J. Bernstein webbased already tools: disclosed the A3.3. testbed lowlow cost. forcost. the security analysis of different IPv6 transition remove the entropy of the source port numbers, thus DNS vulnerability of the DNS systemTESTING as well as the possible solution technologies3. low cost.should contain the fundamental basic blocks of the response. they require that thevulnerabilityAlthough DNSAlthough server of Daniel Danielis the configured DNS J. system Bernstein in a aslive well system. already already as the poss disclosed disclosedible solution the the technologiesAA testbed testbed for should for the the security contain security analysisthe analysis fundamental of ofdifferent different basic IP b v6IPlocks v6transition transition of the servers should never be placed behind NAPT devices unless the inAlthough 1999 [16], Daniel and there J. was Bernstein a CERT already notification disclosed about the the systemsA testbed in which for the the security given solutionsanalysis of are different used. Prac IPv6tically transition it 2. The ID field of the reply packet matches that of the We rather decidedvulnerabilityvulnerabilityin 1999 to build [16], of of a and thethe DNS there, system that was is, a as CERT an wellwell isolated asas notification thethe poss possibleible abo solution solutionut the technologiessystemstechnologies in which should should the contain contain given the solutions the fundamental fundamental are used. basic basic Pracblocks bticallylocks of theof it the NAPT devices are known to comply with RFC 6056 [14], vulnerabilitypossibility of of the the birthday DNS system paradox as wellbased as attacks the poss inible 2002 solution [15], meanstechnologies that we shouldneed a containfew computers the fundamental which are basic interc bonnectedlocks of the question packet. environment, whereinpossibilityin 1999 1999 we [16],can [16], of check the and and birthday there there whether wasparadox the a CERT CERT examinebased notification notification attacksd in 2002 abo about ut[15], the the systemsmeanssystems that in in we which which need the a the few given given computers solutions solutions which are are used.are used. interc Prac Praconnectedticallytically it it which requires randomized source port number selection. insome 1999 mainstream [16], and there DNS was servers a CERT implementations notification includi about ng the bysystems IPv4 and/or in which IPv6 thenetwork(s). given solutions Such systems are used. can be Prac builttically in it DNS64 implementationspossibilitypossibilitysome mainstream ofof indeed thethe birthdaybirthday DNS have serversparadox the presumed implementationsbasedbased attacksattacks inin 2002 2002 includi [15], [15],ng meansbymeans IPv4 that thatand/or we we need IPv6 need a network(s). fewa few computers computers Such which systemswhich are are caninterc interc beonnected builtonnected in RFC 5452 [13] describes another form of attack, which is means that we need a few computers which are interconnected vulnerabilities bypossibilitysome someusing mainstreamany mainstream ofkind the of birthday tests DNS with serversparadox any parameters implementations implementationsbased attacks in 2002 includi includi [15],ngng byby IPv4 IPv4 and/or and/or IPv6 IPv6 network(s). network(s). Such Such systems systems can can be bebuilt built in in based on the birthday paradox. If the attacker may achieve that some mainstream DNS servers implementations including by IPv4 and/or IPv6 network(s). Such systems can be built in the DNS server sends out , that is we consider necessary. queries with identical QNAME, QTYPE, and QCLASS fields, 14 (a new query is sentJUNE while 2018 another • VOLUME one X •still NUMBER waits 2 IV. TESTBED DESIGN AND IMPLEMENTATION for an answer) then the forged replies of the attacker may match any of them, which significantly eases the attack. For further Although we intended to design a testbed for the security details, please refer to the CERT vulnerability note [15]. analysis of DNS64 server implementations, we made our To sum up the essence of the above conditions, we need to considerations with a broader mindset, so that the testbed may check whether the analyzed DNS64 server implementations use also be used for the security analysis of other IPv6 transition hard to predict random numbers for both Transaction IDs and technologies, especially NAT64. source port numbers and they do not send multiple equivalent In general, the requirements for such a testbed usually queries concurrently. include the following: 1. isolated environment, where attacks may be performed III. TOOLS FOR CACHE POISONING VULNERABILITY 2. ease of use TESTING 3. low cost. Although Daniel J. Bernstein already disclosed the A testbed for the security analysis of different IPv6 transition vulnerability of the DNS system as well as the possible solution technologies should contain the fundamental basic blocks of the in 1999 [16], and there was a CERT notification about the systems in which the given solutions are used. Practically it possibility of the birthday paradox based attacks in 2002 [15], means that we need a few computers which are interconnected some mainstream DNS servers implementations including by IPv4 and/or IPv6 network(s). Such systems can be built in INFOCOMMUNICATIONS JOURNAL Methodology for DNS Cache Poisoning Vulnerability 2 333 Analysis of DNS64 Implementations 33 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >>> REPLACE REPLACEREPLACE THISTHIS LINELINE WITHWITH YOUR YOURYOUR PAPER PAPERPAPER IDENTIFICATIONIDENTIFICATION IDENTIFICATION NUMBERNUMBER NUMBER (DOUBLECLICK(DOUBLECLICK (DOUBLECLICK HEREHERE HERE TOTO TO EDIT)EDIT) EDIT) << < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > 3 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < concerning the DNS64 technology and we also elaborate the 3. The response comes from the same network address to > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATIONBINDBIND NUMBER did did not not address address(DOUBLECLICK the the issue issue properly properly HERE TO until until EDIT) the the < C C ERTERT BINDBIND did did not not address address the the issue issue properly properly until until the the C ERT CERT attack model of DNS cache poisoning. In section III, we survey which the question was sent. notificationnotificationBIND did in in not 2008 2008 address [17], [17], the which which issue was was properly triggered triggered until by by the D D CananERT notificationnotification in in 2008 2008 [17], [17], which which was was triggered triggered by by D an D an the available test tools for DNS cache poisoning analysis and 4. The response comes in on the same network address, Kaminsky,Kaminsky,BINDnotification did who whonot in address invented invented 2008 the[17], a a more more issue which powerful powerful properly was cacheuntil cachetriggered the poison poison C byERTinging D an Kaminsky,Kaminsky, who who invented invented a amore more powerful powerful cache cache poison poisoninging point out that they are not suitable for our purposes. In section including port number, from which the question was method.method.notificationKaminsky, His His inattack whoattack 2008 invented is is built [17],built upon upona which more two two waspowerful ideas: ideas: triggered it it cache bypa bypa sses bysses poison D the thean ing method.method. His His attack attack is is built built upon upon two two ideas: ideas: it bypait bypassessses the the IV, we design and implement a testbed for security analysis of sent. protectionprotectionKaminsky,method. of Hisof who thethe attack TTL inventedTTL isbyby built usingusing a more upon differentdifferent powerful two randomrandom ideas: cache itnamnam bypa poisoneses ssesfromfroming the protectionprotection of of the the TTL TTL by by using using different different random random nam names esfrom from DNS64 implementations. In section V, we select the DNS64 In general, the first response matching these four conditions themethod.theprotection attacked attacked His of domain, attackdomain, the TTL is and and built by goes goesusing upon one one different two hierarchy hierarchy ideas: random it level levelbypa nam sses h higher:igher:es the from thethe attacked attacked domain, domain, and and goes goes one one hierarchy hierarchy level level higher: higher: implementations to be tested and also present their setup. In is accepted.” (from section 3 of [13]) insteadprotectioninsteadthe attacked ofof trying tryingof the domain, toto TTL insertinsert by anda a using forgedforged goes different “A”“A” one recordrecord hierarchyrandom intintoo thenamthe level cachecachees from h igher: ofof insteadinstead of of trying trying to to insert insert a forgeda forged “A” “A” record record int into theo the cache cache of of sections VI, VII, and VIII, we design and carry out different Condition 1 gives a very important protection against thetheinstead attackedattacked attacked of trying DNS DNS domain, server, server,to insert and itit hijacksahijacks goes forged one thethe “A” whole hierarchywhole record attacattac int levelkedkedo the zonezone h igher:cache byby of thethe attacked attacked DNS DNS server, server, it ithijacks hijacks the the whole whole attac attackedked zone zone by by tests for the possible components of the DNS cache poisoning spoofed answers by setting up a time limit. This is includingincludinginsteadthe attacked of thetrying the IPDNS IP to address address insertserver, a of of forgedit a ahijacks DNS DNS “A” serverthe server record whole controlled controlled int attaco theked cache by by zone the the of by includingincluding the the IP IP address address of of a aDNS DNS server server controlled controlled by by the the vulnerability, namely, we test Transaction ID and source port equal to the round trip time between the given DNS server and attackerattackertheincluding attacked as as an theanDNS IP IP IP server, address address address it of ofhijacks of a a aDNS DNS DNS the server serverwhole server forattac for controlled the theked a azonettackedttacked by by the attackerattacker as as an an IP IP address address of of a aDNS DNS server server for for the the attacked attacked predictability, as well as whether the DNS64 implementations the authoritative DNS server plus the response time of the domaindomainincludingattacker intointo theas anan an IP AuthorityAuthority IP address address record record of aof DNS ofof a a DNSa forgedforged server server answer answer controlled for forfor the a a by queryquery attacked the domaindomain into into an an Authority Authority record record of ofa forgeda forged answer answer for for a query a query send out multiple equivalent queries simultaneously, which authoritative DNS server. (The latter may be increased by the forforattackerdomain aa randomrandom asinto an namename an IP Authority fromfrom address thethe attacked ofrecordattacked a DNS of zonezone a serverforged (to(to tricktrick foranswer thethe the bailiwick bailiwick aforttacked a query forfor a arandom random name name from from the the attacked attacked zone zone (to (to trick trick the the bailiwick bailiwick would give an opportunity for an attack based on the birthday attacker by a DoS attack against the authoritative DNS server.) rule),rule),domainfor a see seerandom into [18][18] an for forname Authority anan ininfrom depthdepth recordthe andand attacked of wellillustratewellillustrate a forged zone (toanswerd dtrick descriptiondescription for the a bailiwick query ofof rule),rule), see see [18] [18] for for an an in in depth depth and and wellillustrate wellillustrated descriptiond description of of paradox. In section IX, we summarize and discuss our results, In its calculations, the RFC uses 100ms as a typical value for thetheforrule), attack.aattack. random see [18] name for from an in the depth attacked and wellillustrate zone (to trick dthe description bailiwick of the length of this time interval. Of course, an attacker may rule),thethe attack. attack. see [18] for an in depth and wellillustrated description of as well as we make suggestions for the elimination of the Fig.Fig. 1.1. SampleSample TransactionTransaction IDID randomnessrandomness testingtesting reresultssults ofof thethe DNSDNSOARCOARC theThenThen attack. the the alert alert was was taken taken seriously, seriously, and and patches patches wer weree Fig. 1. Sample Transaction ID randomness testing results of the DNSOARC ThenThen the the alert alert was was taken taken seriously, seriously, and and patches patches wer were e uncovered vulnerabilities. Section X concludes our paper. attempt to initiate the opening of this time window at any time Fig. 1. Sample TransactionDNSDNS ID entropyentropy randomness testingtesting testing tool.tool. [20][20] re sults of the DNSOARC preparedpreparedthe attack.Then forfor the allall alert thosethose was majormajor taken DNSDNS seriously, implementationsimplementations and patches ththatat were were wer e Fig. 1. Sample TransactionDNS ID entropy randomness testing testing tool.tool. [20][20] results of the DNSOARC preparedpreparedThen thefor for all alertall those those was major major taken DNS DNS seriously, implementations implementations and patches th atth werewerat weree by sending a request for an arbitrarily chosen domain name. Fig. 1. Sample TransactionDNS ID entropy randomness testing testing tool. [20] results of the DNSOARC stillstillprepared vulnerable.vulnerable. for all AlsoAlso those vulnerabilityvulnerability major DNS testingtesting implementations toolstools werewere preparedprepared that were DNS entropy testing tool. [20] stillstill vulnerable. vulnerable. Also Also vulnerability vulnerability testing testing tools tools were were prepared prepared II. CACHE POISONING VULNERABILITY OF DNS64 However, if a domain name is already cached, it is usually andpreparedand released.released. for all those major DNS implementations that were andandstill released. released.vulnerable. Also vulnerability testing tools were prepared protected, until its TTL expires. stillAA vulnerable.contemporarycontemporary Also webweb vulnerability basedbased TransactionTransaction testing tools IDID andand were sourcesource prepared portport The trustworthy operation of the DNS service is a very andA contemporaryreleased. web based Transaction ID and source port Condition 2 significantly hardens the task of the attacker: the randomnessrandomnessand Areleased. contemporary testertester byby web DNSOARCDNSOARC based Transaction isis stillstill availableavailable ID and [1[1 source9].9]. ItIt is isport important precondition for a secure Internet. The ultimate randomnessA contemporary tester by web DNSOARC based Transaction is still available ID and [1 source9]. It isport attacker has to guess the for a successful attack. documenteddocumentedrandomnessA contemporary and andtester highly highlyweb by DNSOARCbased suggested suggested Transaction by byis still [20]. [20]. ID available and Although Although source [1 9]. port t thehe It is mitigation for DNS cache poisoning, as well as for all other documentedrandomness andtester highly by DNSOARC suggested byis still [20]. available Although [19]. the It is To support guessing, the attacker may send DNS resolution demonstrationdemonstrationrandomnessdocumented tester screenscreen and by highly at atDNSOARC thethe documentationdocumentation suggested is still by does availabledoes [20]. notnot Although seemseem [19]. to toIt be beis the tampering type attacks against DNS, is DNSSEC [10]. demonstrationdocumented screen and highly at the documentation suggested by does [20]. not Althoughseem to be the requests to the DNS server for any domain names, including sosodocumenteddemonstration bad,bad, seesee Fig. Fig. and 1,screen1, highlyourour experienceatexperience the suggested documentation waswas by ratherrather [20]. does poor.poor. Although not WhenWhen seem we twe heto be However, concerning the cache poisoning vulnerability of sodemonstration bad, see Fig. screen1, our atexperience the documentation was rather does poor. not When seem we to be domain names, the authoritative DNS servers of which is under triedtrieddemonstrationso bad, it it out, out, see among amongFig. screen 1, others, others, ourat the experience documentation we we received received was the the ratherdoes results results not poor. seem shown shown When to inbe in we DNS64 servers we cannot rely on DNSSEC for two reasons. triedso bad, it out, see amongFig. 1, others,our experience we received was therather results poor. shown When in we the control of the attacker, thus the attacker may observe an Fig.Fig.sotried bad, 2.2. it We Wesee out, contendFig. contend among 1, our that that others, experience it it is is we not not received was enough enough rather the to to poor. test resultstest onWhen on lyly shown five fivewe in First of all, its deployment rate is still very low. (As of 2016, it Fig.tried 2. it We out, contend among that others, it is we not received enough the to resultstest on ly shown five in arbitrarily long sequence of the Transaction IDs generated by TransactionTransactiontriedFig. it2. out, We IDs.IDs. among contend ButBut others,wewe that dodo notnot we it ishavehave received not anan enough opportunityopportunity the results to test toto shown tune tune only thethe in five was 1.7% among the Alexa top 1 million web servers [11].) The TransactionFig. 2. We IDs. contend But we that do not it ishave not an enough opportunity to test to tune only the five the attacked DNS server. Therefore, DNS servers must use hard tests.tests.Fig.Transaction 2. We contend IDs. But that we itdo isnot not have enough an opportunity to test on toly tune five the other reason is DNS64 specific. The task of a DNS64 server is tests.Transaction IDs. But we do not have an opportunity to tune the to predict (cryptographic) random number generators to prevent Transactiontests.AnotherAnother webbasedwebbased IDs. But we testingtesting do not tooltool have isis mentionedanmentioned opportunity inin thethe to ICANNtuneICANN the to synthesize an [12] for the tests.Another webbased testing tool is mentioned in the ICANN the attacker from being able to predict the Transaction IDs. presentationpresentationtests.Another webbased of of Kim Kim Davies Davies testing [21], [21], tool but butis mentioned the the tool tool is isin nothe no more moreICANN domain names that do not have a AAAA record (IPv6 address). 15 presentation of Kim Davies [21], but the tool is no more Thus, on average, a number of 2 trials are necessary for a presentationAnotherAnother webbased webbased of Kim testing Daviestesting tool tool [21], is ismentioned butmentioned the toolin inthe isthe ICANN no ICANN more However, this a forged address from the DNSSEC point of availableavailable atat thethe URLURL mentionedmentioned onon slideslide 3333 ofof thethe ppresentation:resentation: successful guess for the 16 bit long Transaction ID (within the presentationavailablepresentation at the of of URL Kim Kim mentioned Davies Davies [21], on [21], slide but but 33 the of the toolthe tool p isresentation: isno no more more Fig.Fig. 2.2. OurOur TransactionTransaction IDID randomnessrandomness testtest resultresult pproducedroduced byby thethe DNSDNS http://recursive.iana.org/.http://recursive.iana.org/.available at the URL mentioned on slide 33 of the presentation: view. Thus, a and DNS client has to Fig. 2. Our Transaction ID randomness test result produced by the DNS availablehttp://recursive.iana.org/.available at at the the URL URL mentioned mentioned on on slide slide 33 33 of ofthe the presentation: presentation: given time period of about 100ms). Fig. 2. Our TransactionOARCOARC ID DNSrandomnessDNS entropyentropy test testingtesting result tool.tool. produced by the DNS http://recursive.iana.org/.AndAnd there there isis another another problem problem with with these these webbased webbased t tools:ools: discard it. The best possible mode of operation is, when a OARC DNS entropy testing tool. http://recursive.iana.org/.And there is another problem with these webbased tools: Condition 3 further hardens the task of the attacker, but not Fig.Fig. 2. 2. Our Our TransactionTransactionOARC ID DNSrandomness entropy testtest testing resultresult tool. pproducedroduced by by the the DNS DNS theytheyhttp://recursive.iana.org/.And requirerequire there thatthat is thethe another DNSDNS serverserver problem isis configuredconfigured with these inin webbased aa livelive system.system. tools: security aware client asks the DNS64 server to perform the OARC DNS entropy testing tool. they require that the DNS server is configured in a live system. very significantly. There may be a few authoritative DNS OARC DNS entropy testing tool. theyWeWeAndAnd require rather rather there there decidedis decidedthat is another anotherthe DNS to to problem build build problem server a a with is with configured these ,, these that that webbased is, is,webbased in an ana live isolated isolated t ools:system. tools: validation, see section 3 of [4]. In this case, the client has to We rather decided to build a , that is, an isolated servers for a domain, the IP address of which are known for the environment,environment,theythey require require that that where where the the DNS we weDNS server can can server check check is isconfigured configured whether whether in the theain live a examine examinelive system. system.dd trust in the DNS64 server. (And of course, tampering may whichwhich requiresrequires randomizedrandomized sourcesource portport numbernumber selectselection.ion. environment,We rather where decided we to can build check a whether, that the is, examine an isolatedd attacker, and the DNS server may use them in a round robin which requires randomized source port number selection. DNS64DNS64WeWe rather rather implementations implementations decided decided to to build build indeed indeed a a have have, that , that the the is, is, an presumed presumed an isolated isolated happen while the packet travels from the DNS64 server to the whichRFCRFC requires 54525452 [13][13] randomized describes describes source anotheranother port formform number ofof attack,attack, select whiwhiion.chch is is DNS64environment, implementations where we can indeed check have whether the the presumed examine d manner. The attacker needs to spoof exactly the right one. As whichwhichRFC requiresrequires 5452 [13] randomizedrandomized describes source another port form numbernumber of attack, select select ion.whiion. ch is vulnerabilitiesvulnerabilitiesenvironment,environment, by whereby where usingusing we any weany can kind cankind check of checkof teststests whether whetherwithwith anyany the theparameters parameters examine examined d client.) basedbasedRFC onon 5452 thethe birthdaybirthday[13] describes paradox.paradox. another IfIf thethe attacker attackerform of maymay attack, achieveachieve whi thatchthat is vulnerabilitiesDNS64 implementations by using any kind indeed of tests havewith any the parameters presumed their number is usually small, this condition contributes only basedRFC on 5452 the birthday[13] describes paradox. another If the attackerform of mayattack, achieve which that is weweDNS64DNS64 considerconsider implementations implementationsnecessary.necessary. indeed indeed have have the the presumed presumed Thus for protecting our DNS64 servers from DNS cache basedthetheRFC DNSDNS on 5452 the serverserver birthday[13] sendssends describes paradox. outout another If the attackerform of mayattack, achieve ,whi, thatthatch that isis is wevulnerabilities consider necessary. by using any kind of tests with any parameters with a small multiplication factor. As for the spoofing itself, basedthe DNS on theserver birthday sends paradox. out If the attacker may achieve, that that is vulnerabilitiesvulnerabilities by by using using any any kind kind of oftests tests with with any any parameters parameters poisoning, we need to rely on the guidelines laid down in RFC thebasedqueriesqueries DNS on withwith theserver identicalbirthdayidentical sends paradox.QNAME, QNAME,out If QTYPE,QTYPE, the attacker andand QCLASSQCLASSmay achieve , fie fiethatlds,lds, that is we consider necessary. there are some countermeasures against source IP address thequeriesthe DNSDNS with serverserver identical sendssends QNAME,out QTYPE, and QCLASS, , thatfiethatlds, is is wewe consider considerIV.IV. necessary. necessary.TTESTBEDESTBED DD ESIGNESIGN ANDAND IIMPLEMENTATIONMPLEMENTATION 5452 [13]. Before addressing them, we need to clarify the attack queries with identical (a(a newnew queryquery QNAME, isis sentsent QTYPE, whilewhile anotheranother and QCLASS oneone stillstill waitsfiewaitslds, IV. TESTBED DESIGN AND IMPLEMENTATION spoofing, such as reverse path checking by routers or firewalls. queries with identical(a new query QNAME, is sent QTYPE, while another and QCLASS one still fie waitslds, model, that is, the conditions of a DNS cache poisoning attack. queriesforfor anan answer)answer) with identical(a thenthen new thethe query QNAME, forgedforged is sentrepliesreplies QTYPE, while ofof thethe another and attacattac QCLASSkerker one maymay still matchmatch fie waitslds, IV. TESTBED DESIGN AND IMPLEMENTATION However, we may not rely on this optional protection: we for an answer) (a then new the query forged is sentreplies while of the another attac kerone may still match waits IV.IV. TESTBEDTESTBED D ESIGNDESIGN AND AND IMPLEMENTATION IMPLEMENTATION We always consider , which means that the foranyany an ofof answer) them,them, (awhich whichthen new the significantlyquerysignificantly forged is sentreplies eases easeswhile of thethe another attack.attacattack. kerone ForFor may still furtherfurther match waits suppose that it is not switched on, or the attacker is able to send forany an of answer) them, which then the significantly forged replies eases of thethe attacattack.ker Formay further match AlthoughAlthough we we intended intended to to design design a a testbed testbed for for the the se securitycurity attacker may not intercept the DNS requests from the attacked fordetails,details, an answer) pleaseplease referthenrefer thetoto the theforged CERTCERT replies vulnerabilityvulnerability of the attac notnotkeree [15].[15]. may match Although we intended to design a testbed for the security the forged replies from the “right” direction. anyanydetails, ofof them, them,please whichwhich refer tosignificantly the CERT vulnerability easeseases thethe attack.attack. note [15]. ForFor furtherfurther analysisanalysis of of DNS64 DNS64 server server implementations, implementations, we we made made o ourur DNS server to the authoritative DNS server. The attacker may anyToTo of sum sumthem, upup whichthethe essenceessence significantly ofof thethe aboveabove eases conditions, conditions,the attack. we weFor nn eedeedfurther toto analysisAlthoughAlthough of weDNS64 we intended intended server to to designimplementations, design a testbeda testbed for we for the made the se curityse ocurityur Condition 4 has two contributions. The attacked DNS server details,details,To sum pleaseplease up thereferrefer essence to the CERTof the vulnerabilityabove conditions, notnotee [15]. we[15]. n eed to considerationsconsiderationsAlthough wewithwith intended aa broaderbroader to mindset,mindset, design asoso testbed thatthat thethe for testbedtestbed the semaymaycurity send DNS requests (for any domain name) and forged replies to details,checkcheck whetherwhether please refer thethe analyzedanalyzed to the CERT DNS64DNS64 vulnerability serverserver implementatimplementat note [15].ionsions useuse considerationsanalysisanalysis of of DNS64 DNS64with a serverbroader server implementations, mindset, implementations, so that the we testbed we made made may our o ur may have more than one network interfaces (or more than one checkToTo sum sumwhether upup thethe the essence analyzed of DNS64 the above server conditions,conditions, implementat wewe ionsn needeed use to to alsoalsoanalysis bebe usedused of forfor DNS64 thethe securitysecurity server analysisanalysis implementations, ofof otherother IPvIPv 6 we6 transitiontransition made o ur the attacked DNS server. hardhardTo totosum predictpredict up the randomrandom essence numbersnumbers of the forabovefor bothboth conditions, TransactionTransaction we IDsIDs need andand to considerationsalsoconsiderations be used for with withthe a security abroader broader analysismindset, mindset, of so othersothat that theIPv the testbed6 transitiontestbed may may IP addresses may be assigned to the same interface), but this checkcheckhard towhether whether predict the therandom analyzedanalyzed numbers DNS64 for serverserver both Transaction implementatimplementat ionsIDsions anduse use technologies,technologies,considerations especiallyespecially with a broaderNAT64.NAT64. mindset, so that the testbed may Now, we first quote the most important conditions from RFC checksourcesource whether portport numbersnumbers the analyzed andand theythey DNS64 dodo notnot server sendsend implementatmultiplemultiple eequivalentquivalentions use alsotechnologies,also be be used used forespecially for the the security security NAT64. analysis analysis of ofother other IPv IPv6 transition6 transition number is limited, thus it may be only a small factor. The hardhardsource toto portpredictpredict numbers randomrandom and numbers they do fornot both bothsend Transaction Transactionmultiple equivalent IDs IDs and and alsoInIn general, general,be used thefor the the requirements requirements security analysis for for such such of aother a testbed testbed IPv 6 usu usutransitionallyally 5452, when a DNS server (called as “resolver” in the text) may hardqueriesqueries to predictconcurrently.concurrently. random numbers for both Transaction IDs and technologies,technologies,In general, especially theespecially requirements NAT64. NAT64. for such a testbed usually can be another significant factor, if the DNS server sourcesourcequeries port portconcurrently. numbersnumbers and they do notnot sendsend multiplemultiple eequivalentquivalent includeincludetechnologies, thethe following:following: especially NAT64. accept information from a DNS reply packet, and then interpret source port numbers and they do not send multiple equivalent includeInIn general, general,the following: the the requirements requirements for for such such a testbeda testbed usu usuallyally uses different, hard to predict source port numbers for sending queriesqueries concurrently.concurrently. 1.1.In isolatedisolated general, environment,environment, the requirements wherewhere attacksattacks for such maymay a be be testbed performeperforme usudd ally them for our situation. queriesIII. III.concurrently. TTOOLSOOLS FORFOR CCACHEACHE PPOISONINGOISONING VVULNERABILITYULNERABILITY includeinclude1. isolated the the following: following: environment, where attacks may be performed out its every single request. As port numbers from 0 to 1023 III. TOOLS FOR CACHE POISONING VULNERABILITY include2.2. easeease the ofof following: useuse “DNS data is to be accepted by a resolver if and only if: TTESTINGESTING 1.2.1. isolatedeaseisolated of use environment, environment, where where attacks attacks may may be beperforme performed d cannot be used, the entropy is somewhat less than 16 bits. III.III. TTOOLSOOLS FOR CACHETESTING POISONING VVULNERABILITYULNERABILITY 3.3.1. lowlowisolated cost.cost. environment, where attacks may be performed 1. The question section of the reply packet is equivalent to III. TOOLS FOR CACHE POISONING VULNERABILITY 2.3.2. easelowease cost.of of use use We note that NAT (more exactly: NAPT) devices may AlthoughAlthough Daniel Daniel J. J. Bernstein BernsteinTESTING already already disclosed disclosed the the AA2. testbedtestbed ease forfor of the theuse securitysecurity analysisanalysis ofof differentdifferent IPIPv6v6 transitiontransition that of a question packet currently waiting for a Although Daniel J. BernsteinTESTING already disclosed the A3.3. testbed lowlow cost. forcost. the security analysis of different IPv6 transition remove the entropy of the source port numbers, thus DNS vulnerabilityvulnerability ofof thethe DNSDNS systemsystemTESTING asas wellwell asas thethe posspossibleible solutionsolution technologiestechnologies3. low shouldcost.should containcontain thethe fundamentalfundamental basicbasic bblockslocks ofof thethe response. vulnerabilityAlthoughAlthough of Daniel Daniel the DNS J. system Bernstein as well already already as the poss disclosed disclosedible solution the the technologiesAA testbed testbed for should for the the security contain security analysisthe analysis fundamental of ofdifferent different basic IP b v6IPlocks v6transition transition of the servers should never be placed behind NAPT devices unless the inin 1999 1999 [16], [16], and and there there was was a a CERT CERT notification notification abo aboutut the the systemssystems in in which which the the given given solutions solutions are are used. used. Prac Practicallytically it it 2. The ID field of the reply packet matches that of the inAlthough 1999 [16], Daniel and there J. was Bernstein a CERT already notification disclosed about the the systemsA testbed in which for the the security given solutionsanalysis of are different used. Prac IPv6tically transition it vulnerabilitypossibilitypossibilityvulnerability ofof of ofthethe thethe birthdaybirthday DNS system paradoxparadox as wellbasedwellbased asas attacksattacks thethe poss poss iinnible ible 20022002 solution solution [15],[15], meanstechnologiesmeanstechnologies thatthat wewe should needshouldneed acontaina fewcontainfew computerscomputers the the fundamental fundamental whichwhich are arebasic basic intercinterc blocks bonnectedonnectedlocks of theof the question packet. NAPT devices are known to comply with RFC 6056 [14], vulnerabilitypossibility of of the the birthday DNS system paradox as wellbased as attacks the poss inible 2002 solution [15], meanstechnologies that we shouldneed a containfew computers the fundamental which are basic interc bonnectedlocks of the insomesomein 1999 1999 mainstream mainstream [16], [16], and and thereDNS there DNS was servers servers a CERT CERT implementations implementations notification notification includiabo includi aboutut thengng the bybysystemssystems IPv4IPv4 and/orand/or in in which which IPv6IPv6 the thenetwork(s).network(s). given given solutions solutions SuchSuch systemssystems are are used. used. cancan Prac bebe Practically builtbuilttically inin it it possibilityinpossibilitysome 1999 mainstream [16], ofof thethe and birthdaybirthday there DNS was serversparadox a CERT implementationsbasedbased notification attacksattacks inin 2002 2002 includi abo ut[15], [15], ng the meansbymeanssystems IPv4 that thatand/or in we we which need IPv6 need a thenetwork(s). fewa few given computers computers solutions Such which systemswhich are are used.are caninterc interc be Praconnected builtonnectedtically in it possibilitysomesome mainstream mainstream of the birthday DNS serversparadox implementations implementationsbased attacks in 2002 includi includi [15],ngng bybymeans IPv4 IPv4 thatand/or and/or we IPv6 need IPv6 network(s). a network(s). few computers Such Such systemswhich systems are can caninterc be bebuiltonnected built in in some mainstream DNS servers implementations including by IPv4 and/or IPv6 network(s). Such systems can be built in
JUNE 2018 • VOLUME X • NUMBER 2 15 INFOCOMMUNICATIONS JOURNAL 5 Methodology4 for DNS Cache Poisoning Vulnerability 5 4 >5 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Analysis>4 REPLACE of DNS64 THIS ImplementationsLINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 5> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. between the NAT64 gateway and the IPv4only server. which will be important later. between the NAT64 gateway and the IPv4only server. which will be important later. betweenAlthough the we used NAT64 IPv4 gateway between and the DNS64the IPv4only server and server. the whichWe will tested be important the operation later. of the testbed by issuing the betweenAlthough the we usedNAT64 IPv4 gateway between and the DNS64the IPv4only server and server. the whichWe will tested be important the operation later. of the testbed by issuing the authoritativeAlthough we DNS used server IPv4 during between our the DNS64 DNS64 vulnerabi serverlity and tests, the followingWe tested command the operation on the of the computer: testbed by issuing the Althoughauthoritative we DNS used server IPv4 during between our the DNS64 DNS64 vulnerabi server lity and tests, the followingWe tested command the operation on the of the computer: testbed by issuing the weauthoritative set also an DNS IPv6 server address during at the our authoritative DNS64 vulnerabi DNS lityserver tests, to following command on the computer: authoritativewe set also an DNS IPv6 server address during at the our authoritative DNS64 vulnerabi DNS lityserver tests, to following command on the computer: we set also an IPv6 address at the authoritative DNS server to be able to reach it directly from the client for testing its webe set able also to an reach IPv6 it address directly at fromthe authoritative the client DN for S te serversting itsto operability.be able to reach it directly from the client for testing its The Linux command was used to request a AAAA beoperability. able to reach it directly from the client for testing its The Linux command was used to request a AAAA operability.We also note that the interfaces were not necessary for recordThe for the Linux command was used domain to request name a from AAAA the operability.We also note that the interfaces were not necessary for recordThe for the Linux command was used domain to request name a from AAAA the theWe tests, also we note used that them the for providing interfaces the were virtual not m necessaryachines with for record for the domain name from the Fig. 3. Topology of the test network. the tests, we used them for providing the virtual machines with DNS64 server executed by the host named . theWe tests, also we note used that them the for providing interfaces the were virtual not m necessaryachines with for recordDNS64 for server the executed by the host named domain name. from the Fig. 3. Topology of the test network. Internetthe tests, access,we used whichthem for was providing sometimes the virtual necessary, machines e.g. with for DNS64The DNS server messages executed were by the captured host named by . on the Fig. 3. Topology of the test network. theInternet tests, we access, used whichthem for was providing sometimes the virtual necessary, machines e.g .with for DNS64The DNSserver messages executed wereby the captured host named by . on the installingInternet access, various which packages was under sometimes Debian necessary, Linux. We e.g .have for The DNS interface messages using were the captured by capture filter. The on thesix Internetinstalling access, various which packages was under sometimes Debian necessary, Linux. We e.g .have for The DNS interface messages using were the captured by capture filter. Theon thesix Table 1. Linux and VMware Network Settings for Virtual Machines. separatedinstalling this various communication packages underfrom the Debian testing Linux. commu Wenication, have interface using the capture filter. The six installingseparated this various communication packages underfrom the Debian testing Linux. commu Wenication, have captured packetsinterface are using shown the in Fig. 4. Now capture we shall filter. identify The thesix Table 1. Linux and VMware Network Settings for Virtual Machines. whichseparated happened this communication always through from the the testing interfaces communication, of the captured packetsinterface are using shown the in Fig. 4. Now capture we shall filter. identify The sixthe Table 1. Linux and VMware Network Settings for Virtual Machines. separatedwhich happened this communication always through from the the testing interfacescommunication, of the sixcaptured messages packets and areobserve shown their in Fig. Transaction 4. Now we IDs, shall whi identifych are used the Virtual machine name which happened always through the interfaces of the capturedsix messages packets and are observe shown their in Fig. Transaction 4. Now we IDs, shall whi identifych are used the Virtual machine name virtual computers. tosix match messages the andanswer observe with theirthe query. Transaction We will IDs, experim which entare usedwith RoleVirtual machine name IPv6only client DNS64 server Authoritative DNS server whichvirtual happenedcomputers. always through the interfaces of the sixto matchmessages the andanswer observe with their the query.Transaction We will IDs, experim which areent usedwith virtual computers. themto match later. the answer with the query. We will experiment with Role IPv6only client DNS64 server Authoritative DNS server virtual computers. tothem match later. the answer with the query. We will experiment with Role Linux settings IPv6IPv6only static: client fd00::1/64 IPv6DNS64 static: server fd00::2/64 IPv6Authoritative static: fd00::3/64 DNS server them1. later.Request for a AAAA record from the client to the IPv6 static: fd00::1/64 IPv4 static 10.0.0.2/24 IPv4 static: 10.0.0.3/24 1. Request for a AAAA record from the client to the Linux settings IPv6 static: fd00::1/64 IPv6 static: fd00::2/64 IPv6 static: fd00::3/64 The purpose of this setup was to check whether the testbed them1. later.Request for a AAAA record from the client to the The purpose of this setup was to check whether the testbed 1. DNS64Request server for a with AAAA Transaction record ID from 0x7c4a, the clientgenerated to theby IPv4 DHCP IPv4IPv4 DHCPstatic 10.0.0.2/24 IPv4IPv4 DHCPstatic: 10.0.0.3/24 worksThe purpose properly. of We this have setup installed was to check BIND9 whether [24] tothe bot testbedh the 1. RequestDNS64 server for a with AAAA Transaction record ID from 0x7c4a, the clientgenerated to theby Linux settings worksThe purpose properly. of We this havesetup installed was to check BIND9 whether [24] tothe bot testbedh the theDNS64 server command. with Transaction ID 0x7c4a, generated by Linux settings IPv4 DHCP IPv4 DHCP IPv4 DHCP works properly. We have installed BIND9 [24] to both the DNS64the server command. with Transaction ID 0x7c4a, generated by VMwareLinux settings settings VMnet1IPv4 DHCP VMnet1IPv4 DHCP VMnet1IPv4 DHCP works properly. and the We virtual have installedmachines. BIND9 [24] to both the the command. works properly. and the We virtual have installedmachines. BIND9 [24] to both the 2. Requestthe for command. a AAAA record from the DNS64 server to VMware settings VMnet1 VMnet1 VMnet1 and the virtual machines. 2. theRequest for command. a AAAA record from the DNS64 server to 4 VMwareVMware settingssettings NATVMnet1 NATVMnet1 NATVMnet1 and the virtual machines. 2. theRequest authoritative for a AAAA DNS serverrecord with from a thedifferent DNS64 Trans serveraction to 2. Requestthe authoritative for a AAAA DNS serverrecord withfrom a thedifferent DNS64 Trans serveraction to VMware settings NAT NAT NAT The file was used ID,the authoritative0xcad0, generated DNS serverby BIND. with a different Transaction > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION VMwareNUMBER settings (DOUBLECLICK NAT HERE TO EDIT) < NAT NAT The file was used theID, authoritative0xcad0, generated DNS server by BIND. with a different Transaction to Theset up the DNS64 function. The relevant settings file were: was used 3. AnID, “empty”0xcad0, generatedreply for theby BIND.AAAA record request sent by to Theset up the DNS64 function. The relevant settings file were: was used 3. ID,An 0xcad0,“empty” generated reply for theby BIND.AAAA record request sent by several ways, including the usage of: hosts. As for DNS64, they are: client, DNS64 server and to set up the DNS64 function. The relevant settings were: 3. theAn “empty”authoritative reply DNS for the server AAAA to the record DNS64 request server, sent a ndby several ways, including the usage of: hosts. As for DNS64, they are: client, DNS64 server and to set up the DNS64 function. The relevant settings were: 3. Anthe “empty”authoritative reply DNS for the server AAAA to the record DNS64 request server, sent a bndy several1. server ways, computersincluding the usage of: authoritativehosts. As for DNS DNS64, server, they where are: the client, DNS64 DNS64 server servershould andbe theits authoritative Transaction DNS ID isserver the to same the DNS64 as that server, of a thend its Transaction ID is the same as that of the 2.1. desktopserver computers or laptop computers interconnectedauthoritative DNS with server, both the where client the and DNS64 the authori servertative should DNS be theits authoritative Transaction DNS ID server is the to samethe DNS64 as that server, of a thend correspondingits Transaction request. ID is the same as that of the 3.2. singleboarddesktop or laptop computers computers [22] interconnected with both the client and the authoritative DNS itscorresponding Transaction request. ID is the same as that of the 2. desktop or laptop computers server.interconnected As for with NAT64, both onlythe client the rolesand the are authori different:tative client, DNS 4. Requestcorresponding for an request. A record from the DNS64 server to the 3. singleboard computers [22] 4. correspondingRequest for an request. A record from the DNS64 server to the 4.3. virtualsingleboard machines. computers [22] NAT64server. As gateway for NAT64, and IPv4only only the server; roles are the different: topology is client, the 4. Requestauthoritative for an DNS A recordserver withfrom a thedifferent DNS64 Transacti server onto ID,the The file was used to 4. Requestauthoritative for an DNS A recordserver withfrom a the different DNS64 Transacti server onto thID,e We4. contendvirtual machines.that the consecutive solutions result in less cost same.NAT64 Thus gateway the same and network IPv4only can be server; used for the the topology testing of is the the The file was used to 0xee9d,authoritative generated DNS serverby BIND. with a different Transaction ID, NAT64 gateway and IPv4only server; the topology is the setThe up the authoritative DNS server. The relevant file settings was used were: to authoritative0xee9d, generated DNS serverby BIND. with a different Transaction ID, andWe higher contend comfort that in the use consecutive including easysolutions mobility. result Our in decisionless cost differentsame. Thus implementations the same network of both can IPv6be used transition for the ttesechnologies,ting of the setThe up the authoritative DNS server. The relevant file s ettingswas used were: to 5. A0xee9d, valid replygenerated with byan BIND.A record sent by the authoritative same. Thus the same network can be used for the testing of the set up the authoritative DNS server. The relevant settings were: 5. 0xee9d,A valid replygenerated with byan BIND.A record sent by the authoritative wasand higheralso influenced comfort in by use the including fact that easywe have mobility. been Oursuccessfully decision onlydifferent some implementations software components of both need IPv6 to transition be changed. technologies, set up the authoritative DNS server. The relevant settings were: 5. ADNS valid server reply to with the DNS64an A record server, sent and by its the Transaction authoritative ID different implementations of both IPv6 transition technologies, 5. ADNS valid server reply to with the DNS64an A record server, sent and by its the Transaction authoritative ID usingwas also virtual influenced Linux boxes by the (executed fact that weunder have Windows been successfully 7) for the only some software components need to be changed. DNSis the serversame asto thatthe DNS64of the corresponding server, and its request. Transaction ID onlyAs somefor the software attacker, components two further need hosts to could be changed. have been added, DNSis the serversame asto thatthe DNS64of the corresponding server, and its request. Transaction ID practicalusing virtual education Linux boxes of DNS64 (executed and under NAT64 Windows IPv6 transit7) for ionthe As for the attacker, two further hosts could have been added, 6. Theis the reply same of as the that DNS64 of the correspondingserver to the client request. contain ing oneAs for for tampering the attacker, with two each further connections, hosts could but have we b elieenminated added, 6. isThe the reply same of as the that DNS64 of the correspondingserver to the clientrequest. contain ing technologiespractical education at the Budapest of DNS64 University and NAT64 of Technolo IPv6 transitgy andion one for tampering with each connections, but we eliminated 6. theThe synthesized reply of the DNS64 server to the client contain [12] withing practical education of DNS64 and NAT64 IPv6 transition themone forwith tampering a trick. First with of each all, we connections, used a single but s hared we eli mediumminated 6. Thethe synthesizedreply of the DNS64 server to the client contain [12] withing technologies at the Budapest University of Technology and The content of the file was: the synthesized [12] with Economicstechnologies since at the2015. Budapest University of Technology and tothem interconnect with a trick. the First three of computers, all, we used see a singleFig. 3, s haredthus only medium one The content of the file was: the same Transaction ID as message 1. The content of the file was: thethe synthesizedsame Transaction ID as message 1. [12] with EconomicsAs the existing since 2015.virtual machine images were suitable for our extrato interconnect device would the three have computers, been enough. see Fig. However, 3, thus as only in ourone The content of the file was: Thusthe we same have Transaction found that theID testbedas message worked 1. fine, and it was to interconnect the three computers, see Fig. 3, thus only one Thusthe we same have Transaction found that theID astestbed message worked 1. fine, and it was currentAs the testing existing purposes, virtual itmachine was a convenientimages were solut suitablion eto for reuse our currentextra device tests we would used haveonly wiretapping, been enough. it could However, be done as inat any our readyThus for we testing. have found that the testbed worked fine, and it was extra device would have been enough. However, as in our readyThus for we testing. have found that the testbed worked fine, and it was them.current The testing virtual purposes, machine it wasimages a convenient were prepared solut ion by ato scriptreuse ofcurrent the three tests computers, we used only thus wiretapping, no further computer it could wabe sdone necessary. at any ready for testing. current tests we used only wiretapping, it could be done at any ready for testing. calledthem. The virtual machine, written imagesby Dániel were Bakai prepared [23]. (This by a script script of the three computers, thus no further computer was necessary. V. DNS64 IMPLEMENTATION SELECTION AND SETUP Fig. 3. Topology of the test network. of the three computers, thus no further computer was necessary. V. DNS64 IMPLEMENTATION SELECTION AND SETUP createscalled a small, low memory, written usage, by Dániel userdefined Bakai [23]. Deb (Thisian virtual script WeV. have DNS64 laid down IMPLEMENTATION our implementations SELECTION selection AND guiSETUPdelines WeV. have DNS64 laid down IMPLEMENTATION our implementations SELECTION selection AND guiSETUPdelines machinecreates a disksmall, image, low memory which can usage, be used userdefined in various Deb hyianpervisors virtual We have implemented the test network shown in Fig. 3 by in We[2] ashave follows: laid down our implementations selection guidelines 5 in We[2] ashave follows: laid down our implementations selection guidelines includingmachine disk VMware image, which and KVM.) can be used They in containvarious hy Debianpervisors 8 threeWe virtual have implementedmachines, each the of test which network had ashown single in CPU Fig. core, 3 by in [2] as follows: Table 1. Linux and VMware Networkmachine Settings fordisk Vir image,tual Machines. which can be used in various hypervisors > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < “As for the implementations, we only deal with those that are including VMware and KVM.) They contain Debian 8 128MBthree virtual of RAM, machines, and (theoretically) each of which 40GB had aof single hard CPUdisks, core, but in [2]“As as for follows: the implementations, we only deal with those that are distributions,including VMware which were and now KVM.) updated They to Debian contain ver Debiansion 8.9. 8 three virtual machines, each of which had a single CPU core, free“As software for the implementations,[25] (also called weopen only source deal with[26]) thos for emultiple that are Virtual machine name 128MB of RAM, and (theoretically) 40GB of hard disks, but free“As software for the implementations,[25] (also called weopen only source deal with[26]) thos for emultiple that are Theydistributions, were executed which bywere VMware now updated Workstation to Debian 12 Player. version 8.9. the128MB starting of RAM,size of and the (theoretically)images were under40GB 1GB.of hard (Th diskey s,were but reasons:free software [25] (also called open source [26]) for multiple freereasons: software [25] (also called open source [26]) for multiple Role IPv6only client They were executedDNS64 server by VMware WorkstationAuthoritative 12 DPlayer.NS server growingthe starting during size theof the experiments, images were but under remained 1GB. under (They 3GB.) were reasons: They were executed by VMware Workstation 12 Player. The licenses of certain vendors (e.g. [27] and [28]) do Tablegrowing 1 shows during the the Linux experiments, and WMware but remained settings underused fo3GB.)r the reasons: The licenses of certain vendors (e.g. [27] and [28]) do Linux settings IPv6 static: fd00::1/64 IPv6 static: fd00::2/64 IPv6 static: fd00::3/64 growing during the experiments, but remained under 3GB.) notThe allowlicenses reverse of certain engineering vendors and (e.g. sometimes [27] and even[28]) th doe Table 1 shows the Linux and WMware settings used for the Thenot allowlicenses reverse of certain engineering vendors and (e.g. sometimes [27] and even[28]) th doe We proposeIPv4 the static structure 10.0.0.2/24 of a simpleIPv4 testbed static: suitab10.0.0.3/24le for the virtualTable 1machines. shows the Linux and WMware settings used for the publicationnot allow reverse of benchmarking engineering results and sometimes is prohibited. even the publication of benchmarking results is prohibited. IPv4 DHCP securityWe propose analysisIPv4 the DHCPof structure the DNS64 of a andsimple theIPv4 testbed stateful DHCP suitab NATle64 for IPv6 the virtualWe note machines. that the IP version between the client, which is an notpublication allow reverse of benchmarking engineering results and sometimes is prohibited. even the Linux settings virtual machines. Freepublication software of benchmarkingcan be used by results anyone is prohibited.for any purpose s transitionsecurity analysis technologies. of the SimilarDNS64 testbedsand the stateful can be NAT built 64 for IPv6 the IPv6onlyWe note client, that the and IP the version DNS64 between server mustthe client, be 6. Twhiherech isis noan publicationFree software of benchmarkingcan be used by results anyone is prohibited.for any purpose s VMware settings VMnet1 VMnet1 VMnet1 We note that the IP version between the client, which is an thusFree oursoftware results can can be be used helpful by foranyone anyone. for any purposes securitytransition analysis technologies. of other SimilarIPv6 transition testbeds technolo can be gies. built for the IPv6only client, and the DNS64Fig. server4. Wireshark must capture be 6. takenThere during is no the functional checking of the DNS64 testbed. Freethus oursoftware results can can be be used helpful by foranyone anyone. for any purposes transition technologies. Similar testbeds can be built for the restrictionIPv6only forclient, the IPand version the DNS64 between server the mustDNS64 be se6.rver There and is the no In this section, we demonstrate the correct operation of the Freethus oursoftware results is can available be helpful free forof charge anyone. for us, too. VMware settings NAT security analysisNAT of other IPv6 transitionNAT technolo gies. In this section, we demonstrate the correct operation of the thusFree oursoftware results is can available be helpful free forof chargeanyone. for us, too. securityThe testing analysis of DNS64of other or IPv6 NAT64 transition requires technolo a networkgies. of three DNSrestriction server, for butthe IP when version testing between NAT64, the DNS64 IPv4 must server be and us theed testIn system, this section, and also we introduce demonstrate the operationthe correct of operatiDNS64on servers, of the Within Free the software category is of available the free freesoftware of charge implementa for us, tions,too. we The testing of DNS64 or NAT64 requires a network of three testIn system, this section, and also we introduce demonstrate the operationthe correct of operati DNS64on servers, of the Within Free the software category is ofavailable the free freesoftware of charge implementa for us, tions,too. we The testing of DNS64 or NAT64 requires a network of three betweenDNS server, the but NAT64 when gateway testing NAT64, and the IPv4 IPv4only must be server. used which will be importanttest system, later. and also introduce the operation of DNS64 servers, Within the category of the free software implementations, we test system, and also introduce the operation of DNS64 servers, several ways, including the usage of: hosts. As for DNS64, they are: client, DNS64 server and Although we used IPv4 between the DNS64 server and the We tested the operation of the testbed by issuing the Within the category of the free software implementations, we 1. server computers authoritative DNS server, where the DNS64 server should be authoritative DNS server during our DNS64 vulnerability tests, following command on the computer: 2. desktop or laptop computers interconnected with both the client and the authoritative DNS we set also an IPv6 address at the authoritative DNS server to 3. singleboard computers [22] server. As for NAT64, only the roles are different: client, be able to reach it directly from the client for testing its 4. virtual machines. NAT64 gateway and IPv4only server; the topology is the operability. The Linux command was used to request a AAAA We contend that the consecutive solutions result in less cost 16same. Thus the same network can be used for the testing of the We also note that the interfacesJUNE 2018 were • VOLUME not necessary X • NUMBER for 2 record for the domain name from the and higher comfort in use including easy mobility. Our decision different implementations of both IPv6 transition technologies, the tests, we used them for providing the virtual machines with DNS64 server executed by the host named . was also influenced by the fact that we have been successfully only some software components need to be changed. Internet access, which was sometimes necessary, e.g. for The DNS messages were captured by on the using virtual Linux boxes (executed under Windows 7) for the As for the attacker, two further hosts could have been added, installing various packages under Debian Linux. We have interface using the capture filter. The six practical education of DNS64 and NAT64 IPv6 transition one for tampering with each connections, but we eliminated separated this communication from the testing communication, captured packets are shown in Fig. 4. Now we shall identify the technologies at the Budapest University of Technology and them with a trick. First of all, we used a single shared medium which happened always through the interfaces of the six messages and observe their Transaction IDs, which are used Economics since 2015. to interconnect the three computers, see Fig. 3, thus only one virtual computers. As the existing virtual machine images were suitable for our to match the answer with the query. We will experiment with extra device would have been enough. However, as in our them later. current testing purposes, it was a convenient solution to reuse current tests we used only wiretapping, it could be done at any 1. Request for a AAAA record from the client to the them. The virtual machine images were prepared by a script The purpose of this setup was to check whether the testbed of the three computers, thus no further computer was necessary. DNS64 server with Transaction ID 0x7c4a, generated by called , written by Dániel Bakai [23]. (This script works properly. We have installed BIND9 [24] to both the the command. creates a small, low memory usage, userdefined Debian virtual and the virtual machines. 2. Request for a AAAA record from the DNS64 server to machine disk image, which can be used in various hypervisors We have implemented the test network shown in Fig. 3 by the authoritative DNS server with a different Transaction three virtual machines, each of which had a single CPU core, including VMware and KVM.) They contain Debian 8 The file was used ID, 0xcad0, generated by BIND. 128MB of RAM, and (theoretically) 40GB of hard disks, but distributions, which were now updated to Debian version 8.9. to set up the DNS64 function. The relevant settings were: 3. An “empty” reply for the AAAA record request sent by They were executed by VMware Workstation 12 Player. the starting size of the images were under 1GB. (They were the authoritative DNS server to the DNS64 server, and growing during the experiments, but remained under 3GB.) its Transaction ID is the same as that of the Table 1 shows the Linux and WMware settings used for the corresponding request. We propose the structure of a simple testbed suitable for the virtual machines. 4. Request for an A record from the DNS64 server to the security analysis of the DNS64 and the stateful NAT64 IPv6 We note that the IP version between the client, which is an authoritative DNS server with a different Transaction ID, The file was used to transition technologies. Similar testbeds can be built for the IPv6only client, and the DNS64 server must be 6. There is no 0xee9d, generated by BIND. set up the authoritative DNS server. The relevant settings were: security analysis of other IPv6 transition technologies. restriction for the IP version between the DNS64 server and the 5. A valid reply with an A record sent by the authoritative The testing of DNS64 or NAT64 requires a network of three DNS server, but when testing NAT64, IPv4 must be used DNS server to the DNS64 server, and its Transaction ID is the same as that of the corresponding request. 6. The reply of the DNS64 server to the client containing the synthesized [12] with The content of the file was: the same Transaction ID as message 1. Thus we have found that the testbed worked fine, and it was ready for testing. V. DNS64 IMPLEMENTATION SELECTION AND SETUP We have laid down our implementations selection guidelines in [2] as follows: “As for the implementations, we only deal with those that are free software [25] (also called open source [26]) for multiple reasons: The licenses of certain vendors (e.g. [27] and [28]) do not allow reverse engineering and sometimes even the publication of benchmarking results is prohibited. Free software can be used by anyone for any purposes thus our results can be helpful for anyone. In this section, we demonstrate the correct operation of the Free software is available free of charge for us, too. test system, and also introduce the operation of DNS64 servers, Within the category of the free software implementations, we INFOCOMMUNICATIONS JOURNAL 5 4 5 Methodology for DNS Cache Poisoning Vulnerability 4 5>5 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >4 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 5> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICKAnalysis of DNS64 HERE ImplementationsTO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > > REPLACEREPLACE THISTHIS LINELINE WITHWITH YOURYOUR PAPERPAPER IDENTIFICATIONIDENTIFICATION NUMBERNUMBER (DOUBLECLICK(DOUBLECLICK HEREHERE TOTO EDIT)EDIT) << > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. Fig.Fig. 4. 4. Wireshark Wireshark capture capture taken taken during during the the function functionalal checking checking of of the the DNS64 DNS64 testbed. testbed. Fig. 4. Wireshark capture taken during the functional checking of the DNS64 testbed. between the NAT64 gateway and the IPv4only server. which will be important later. between the NAT64 gateway and the IPv4only server. which will be important later. betweenbetweenAlthough the the we NAT64used NAT64 IPv4 gateway gateway between and and the the DNS64the IPv4only IPv4only server and server. server. the whichwhichWe willwill tested bebe importantimportant the operation later.later. of the testbed by issuing the betweenAlthough the we usedNAT64 IPv4 gateway between and the DNS64the IPv4only server and server. the whichWe will tested be important the operation later. of the testbed by issuing the AlthoughauthoritativeAlthough we we DNS used used server IPv4 IPv4 betweenduring between our the the DNS64 DNS64 DNS64 vulnerabi server server lity and and tests, thethe followingWeWe tested tested command the the operation operation on the of of the the computer: testbed testbed by by issuing issuing t thehe Althoughauthoritative we DNS used server IPv4 during between our the DNS64 DNS64 vulnerabi server lity and tests, the followingWe tested command the operation on the of the computer: testbed by issuing the authoritativeweauthoritative set also an DNSDNS IPv6 serverserver address during during at the ourour authoritative DNS64 DNS64 vulnerabi vulnerabi DNS litylityserver tests, tests, to followingfollowing commandcommand onon thethe computer:computer: authoritativewe set also an DNS IPv6 server address during at the our authoritative DNS64 vulnerabi DNS lityserver tests, to following command on the computer: we set also an IPv6 address at the authoritative DNS server to webe set able also to an reach IPv6 itaddress directly at the from authoritative the client DN for S teserversting to its webe set able also to an reach IPv6 it address directly at fromthe authoritative the client DN for S te serversting itsto beoperability.be able able to to reach reach it it directly directly from from the the client client for for te testingsting its its The Linux command was used to request a AAAA beoperability. able to reach it directly from the client for testing its The Linux command was used to request a AAAA operability.operability.We also note that the interfaces were not necessary for recordTheThe for the Linux Linux command command waswas used used domain to to request request name a a from AAAA AAAA the operability.We also note that the interfaces were not necessary for recordThe for the Linux command was used domain to request name a from AAAA the theWeWe tests, also also we note note used that that them the the for providing interfaces interfaces the were were virtual not not m necessary necessaryachines with for for recordrecord forfor thethe domaindomain namename fromfrom thethe Fig. 3. Topology of the test network. the tests, we used them for providing the virtual machines with DNS64 server executed by the host named . theWe tests, also we note used that them the for providing interfaces the were virtual not m necessaryachines with for recordDNS64 for server the executed by the host named domain name. from the Fig. 3. Topology of the test network. theInternetthe tests,tests, we access,we usedused them whichthem forfor was providingproviding sometimes thethe virtualvirtual necessary, mmachinesachines e.g . with with for DNS64DNS64The DNS serverserver messages executedexecuted were byby thethe captured hosthost namednamed by .. on the Fig. 3. Topology of the test network. theInternet tests, we access, used whichthem for was providing sometimes the virtual necessary, machines e.g .with for DNS64The DNSserver messages executed wereby the captured host named by . on the InternetinstallingInternet access, access, various which which packages was was under sometimes sometimes Debian necessary, necessary, Linux. We e.g e.g .. have for for TheThe DNSDNS interface messagesmessages using werewere the capturedcaptured byby capture filter. The onon thethesix Internetinstalling access, various which packages was under sometimes Debian necessary, Linux. We e.g .have for The DNS interface messages using were the captured by capture filter. Theon thesix Table 1. Linux and VMware Network Settings for Virtual Machines. installingseparatedinstalling this various various communication packages packages under underfrom the Debian Debian testing Linux. Linux. commu We Wenication, havehave interface using the capture filter. The six installingseparated this various communication packages underfrom the Debian testing Linux. commu Wenication, have captured packetsinterfaceinterface are usingusing shown thethe in Fig. 4. Now capturecapture we shall filter.filter. identify TheThe sixthesix Table 1. Linux and VMware Network Settings for Virtual Machines. separatedwhichseparated happened thisthis communicationcommunication always through fromfrom the thethe testing testing interfaces commucommunication,nication, of the captured packetsinterface are using shown the in Fig. 4. Now capture we shall filter. identify The sixthe Table 1. Linux and VMware Network Settings for Virtual Machines. separatedwhich happened this communication always through from the the testing interfacescommunication, of the capturedsixcaptured messages packets packets and are areobserve shownshown their in in Fig. Fig. Transaction 4.4. Now Now we we IDs, shall shall whi identifyidentifych are used the the Virtual machine name whichwhich happened happened always always through through the the interfaces interfaces of of the the capturedsix messages packets and are observe shown their in Fig. Transaction 4. Now we IDs, shall whi identifych are used the Virtual machine name virtual computers. sixtosix matchmessages messages the and andanswer observe observe with their theirthe query.Transaction Transaction We will IDs, IDs, experim whi whichch are entare usedusedwith RoleVirtual machine name IPv6only client DNS64 server Authoritative DNS server whichvirtual happenedcomputers. always through the interfaces of the sixto matchmessages the andanswer observe with their the query.Transaction We will IDs, experim which areent usedwith virtualvirtual computers.computers. tothemto matchmatch later. thethe answeranswer withwith thethe query.query. WeWe willwill experimexperimentent withwith Role IPv6only client DNS64 server Authoritative DNS server virtual computers. tothem match later. the answer with the query. We will experiment with Role Linux settings IPv6IPv6only static: client fd00::1/64 IPv6DNS64 static: server fd00::2/64 IPv6Authoritative static: fd00::3/64 DNS server themthem1. later.later.Request for a AAAA record from the client to the IPv6 static: fd00::1/64 IPv4 static 10.0.0.2/24 IPv4 static: 10.0.0.3/24 1. Request for a AAAA record from the client to the Linux settings IPv6 static: fd00::1/64 IPv6 static: fd00::2/64 IPv6 static: fd00::3/64 The purpose of this setup was to check whether the testbed them1. later.Request for a AAAA record from the client to the The purpose of this setup was to check whether the testbed 1.1. RequestDNS64Request server for for a a with AAAA AAAA Transaction record record fromID from 0x7c4a, the the client clientgenerated to to the theby IPv4 DHCP IPv4IPv4 DHCPstatic 10.0.0.2/24 IPv4IPv4 DHCPstatic: 10.0.0.3/24 worksTheThe purposepurpose properly. ofof We thisthis have setupsetup installed waswas toto check check BIND9 whetherwhether [24] tothethe bot testbedtestbedh the 1. RequestDNS64 server for a with AAAA Transaction record ID from 0x7c4a, the clientgenerated to theby Linux settings worksThe purpose properly. of We this havesetup installed was to check BIND9 whether [24] tothe bot testbedh the DNS64theDNS64 server server command. with with Transaction Transaction ID ID 0x7c4a, 0x7c4a, generated generated by by Linux settings IPv4 DHCP IPv4 DHCP IPv4 DHCP works properly. We have installed BIND9 [24] to both the DNS64the server command. with Transaction ID 0x7c4a, generated by VMwareLinux settings settings VMnet1IPv4 DHCP VMnet1IPv4 DHCP VMnet1IPv4 DHCP worksworks properly.properly. and the We We virtual have have installed installedmachines. BIND9 BIND9 [24] [24] to to bot bothh the the the command. works properly. and the We virtual have installedmachines. BIND9 [24] to both the 2. theRequestthe for command.command. a AAAA record from the DNS64 server to VMware settings VMnet1 VMnet1 VMnet1 andand thethe virtualvirtual machines.machines. 2. theRequest for command. a AAAA record from the DNS64 server to VMwareVMware settingssettings NATVMnet1 NATVMnet1 NATVMnet1 and the virtual machines. 2.2. RequesttheRequest authoritative forfor aa AAAAAAAA DNS recordserverrecord with fromfrom a the thedifferent DNS64DNS64 Trans serverserveraction toto 2. Requestthe authoritative for a AAAA DNS serverrecord withfrom a thedifferent DNS64 Trans serveraction to VMware settings NAT NAT NAT The file was used theID,the authoritative authoritative0xcad0, generated DNS DNS server serverby BIND. with with a a different different Trans Transactionaction VMware settings NAT NAT NAT The file was used theID, authoritative0xcad0, generated DNS server by BIND. with a different Transaction toThe Theset up the DNS64 function. The relevant settings filefile were: waswas usedused 3. ID,AnID, 0xcad0,“empty”0xcad0, generated generatedreply for bytheby BIND. BIND.AAAA record request sent by to Theset up the DNS64 function. The relevant settings file were: was used 3. ID,An 0xcad0,“empty” generated reply for theby BIND.AAAA record request sent by several ways, including the usage of: hosts. As for DNS64, they are: client, DNS64 server and toto setset upup thethe DNS64DNS64 function.function. TheThe relevantrelevant settingssettings were:were: 3.3. AntheAn “empty”“empty”authoritative replyreply DNS forfor thethe server AAAAAAAA to the recordrecord DNS64 requestrequest server, sentsent a bndbyy several ways, including the usage of: hosts. As for DNS64, they are: client, DNS64 server and to set up the DNS64 function. The relevant settings were: 3. Anthe “empty”authoritative reply DNS for the server AAAA to the record DNS64 request server, sent a bndy several1. server ways, computersincluding the usage of: authoritativehosts. As for DNS DNS64, server, they where are: the client, DNS64 DNS64 server servershould andbe theitsthe authoritativeauthoritative Transaction DNSDNS ID server isserver the to to same thethe DNS64DNS64 as that server,server, of aa thendnd its Transaction ID is the same as that of the 2.1. desktopserver computers or laptop computers interconnectedauthoritative DNS with server, both the where client the and DNS64 the authori servertative should DNS be theits authoritative Transaction DNS ID server is the to samethe DNS64 as that server, of a thend itscorrespondingits Transaction Transaction request. ID ID is is the the same same as as that that of of the the 3.2. singleboarddesktop or laptop computers computers [22] interconnected with both the client and the authoritative DNS itscorresponding Transaction request. ID is the same as that of the 2. desktop or laptop computers server.interconnected As for with NAT64, both onlythe client the rolesand the are authori different:tative client, DNS 4. correspondingRequestcorresponding for an request.request. A record from the DNS64 server to the 3. singleboard computers [22] 4. correspondingRequest for an request. A record from the DNS64 server to the 4.3. virtualsingleboard machines. computers [22] NAT64server. As gateway for NAT64, and IPv4only only the server; roles are the different: topology is client, the 4.4. RequestauthoritativeRequest forfor anan DNS AA record recordserver fromwithfrom a the thedifferent DNS64DNS64 Transacti serverserver toonto thID,thee The file was used to 4. Requestauthoritative for an DNS A recordserver withfrom a the different DNS64 Transacti server onto thID,e We4. contendvirtual machines.that the consecutive solutions result in less cost same.NAT64 Thus gateway the same and network IPv4only can be server; used for the the topology testing of is the the The file was used to authoritative0xee9d,authoritative generated DNS DNS server serverby BIND. with with a a different different Transacti Transactionon ID, ID, NAT64 gateway and IPv4only server; the topology is the setTheThe up the authoritative DNS server. The relevant filefile s ettings waswas usedused were: toto authoritative0xee9d, generated DNS serverby BIND. with a different Transaction ID, andWe higher contend comfort that in the use consecutive including easysolutions mobility. result Our in decisionless cost differentsame. Thus implementations the same network of both can IPv6be used transition for the ttesechnologies,ting of the setThe up the authoritative DNS server. The relevant file s ettingswas used were: to 5. 0xee9d,A0xee9d, valid generatedreplygenerated with by byan BIND. BIND.A record sent by the authoritative same. Thus the same network can be used for the testing of the setset up up the the authoritativeauthoritative DNSDNS server. server. The The relevantrelevant ssettingsettings were:were: 5. 0xee9d,A valid replygenerated with byan BIND.A record sent by the authoritative wasand higheralso influenced comfort in by use the including fact that easywe have mobility. been Oursuccessfully decision onlydifferent some implementations software components of both need IPv6 to transition be changed. technologies, set up the authoritative DNS server. The relevant settings were: 5.5. ADNSA validvalid server replyreply to withwith the DNS64anan AA recordrecord server, sentsent and byby its thethe Transaction authoritauthoritativeative ID different implementations of both IPv6 transition technologies, 5. ADNS valid server reply to with the DNS64an A record server, sent and by its the Transaction authoritative ID usingwas also virtual influenced Linux boxes by the (executed fact that weunder have Windows been successfully 7) for the only some software components need to be changed. DNSisDNS the server serversame toasto thethatthe DNS64 DNS64of the corresponding server,server, andand itsits request. TransactionTransaction IDID onlyAs somefor the software attacker, components two further need hosts to could be changed. have been added, DNSis the serversame asto thatthe DNS64of the corresponding server, and its request. Transaction ID practicalusing virtual education Linux boxes of DNS64 (executed and under NAT64 Windows IPv6 transit7) for ionthe As for the attacker, two further hosts could have been added, 6. isTheis thethe reply samesame of asas the thatthat DNS64 ofof thethe corresponding correspondingserver to the client request.request. contain ing oneAs for for tampering the attacker, with two each further connections, hosts could but have we b elieenminated added, 6. isThe the reply same of as the that DNS64 of the correspondingserver to the clientrequest. contain ing technologiespractical education at the Budapest of DNS64 University and NAT64 of Technolo IPv6 transitgy andion one for tampering with each connections, but we eliminated 6.6. ThetheThe synthesized replyreply ofof thethe DNS64DNS64 serverserver toto thethe clientclient containcontain [12] withinging practical education of DNS64 and NAT64 IPv6 transition themone forwith tampering a trick. First with of each all, we connections, used a single but s hared we eli mediumminated 6. Thethe synthesizedreply of the DNS64 server to the client contain [12] withing technologies at the Budapest University of Technology and The content of the file was: the synthesized [12] with Economicstechnologies since at the2015. Budapest University of Technology and tothem interconnect with a trick. the First three of computers, all, we used see a singleFig. 3, s haredthus only medium one The content of the file was: thethe synthesizedsame Transaction ID as message 1. [12] with TheThe contentcontent ofof thethe filefile was:was: thethe synthesizedsame Transaction ID as message 1. [12] with EconomicsAs the existing since 2015.virtual machine images were suitable for our extrato interconnect device would the three have computers, been enough. see Fig. However, 3, thus as only in ourone The content of the file was: Thusthethe we samesame have TransactionTransaction found that theIDID astestbedas messagemessage worked 1.1. fine, and it was to interconnect the three computers, see Fig. 3, thus only one Thusthe we same have Transaction found that theID astestbed message worked 1. fine, and it was currentAs the testing existing purposes, virtual itmachine was a convenientimages were solut suitablion eto for reuse our currentextra device tests we would used haveonly wiretapping, been enough. it could However, be done as inat any our readyThusThus for wewe testing. havehave found found thatthat thethe testbedtestbed workedworked fine,fine, anandd itit waswas extra device would have been enough. However, as in our readyThus for we testing. have found that the testbed worked fine, and it was them.current The testing virtual purposes, machine it wasimages a convenient were prepared solut ion by ato scriptreuse ofcurrent the three tests computers, we used only thus wiretapping, no further computer it could wabe sdone necessary. at any readyready forfor testing.testing. current tests we used only wiretapping, it could be done at any ready for testing. calledthem. The virtual machine, written imagesby Dániel were Bakai prepared [23]. (This by a script script of the three computers, thus no further computer was necessary. V. DNS64 IMPLEMENTATION SELECTION AND SETUP of the three computers, thus no further computer was necessary. V. DNS64 IMPLEMENTATION SELECTION AND SETUP createscalled a small, low memory, written usage, by Dániel userdefined Bakai [23]. Deb (Thisian virtual script V.V. DNS64DNS64 I IMPLEMENTATIONMPLEMENTATION S SELECTIONELECTION AND AND S SETUPETUP called , written by Dániel Bakai [23]. (This script WeV. have DNS64 laid down IMPLEMENTATION our implementations SELECTION selection AND guiSETUPdelines creates a small, low memory usage, userdefined Debian virtual We have implemented the test network shown in Fig. 3 by We have laid down our implementations selection guidelines machinecreates a disksmall, image, low memory which can usage, be used userdefined in various Deb hyianpervisors virtual inWe We[2] have ashave follows: laid laid down down our our implementations implementations selection selection gui guidelinesdelines machine disk image, which can be used in various hypervisors threeWe virtual have implementedmachines, each the of test which network had ashown single in CPU Fig. core, 3 by in We[2] ashave follows: laid down our implementations selection guidelines includingmachine disk VMware image, which and KVM.) can be used They in containvarious hy Debianpervisors 8 We have implemented5 the test network shown in Fig. 3 by inin [2]“As[2] asas for follows:follows: the implementations, we only deal with those that are including VMware and KVM.) They contain Debian 8 128MBthree virtual of RAM, machines, and (theoretically) each of which 40GB had aof single hard CPUdisks, core, but in [2]“As as for follows: the implementations, we only deal with those that are distributions,including VMware which were and now KVM.) updated They to Debian contain ver Debiansion 8.9. 8 three virtual machines,> REPLACE each of which THIS had LINE a single WITH CPU YOUR core, PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < free“As“As software for for the the implementations,implementations,[25] (also called we weopen only only source deal deal withwith[26]) thos thos fore e multiplethat that are are distributions, which were now updated to Debian version 8.9. the128MB starting of RAM,size of and the (theoretically)images were under40GB 1GB.of hard (Th diskey s,were but free“As software for the implementations,[25] (also called weopen only source deal with[26]) thos for emultiple that are Theydistributions, were executed which bywere VMware now updated Workstation to Debian 12 Player. version 8.9. 128MB of RAM, and (theoretically) 40GB of hard disks, but freereasons:free softwaresoftware [25][25] (also(also calledcalled openopen sourcesource [26])[26]) fforor multiplemultiple the starting size of the images were under 1GB. (They were freereasons: software [25] (also called open source [26]) for multiple They were executed by VMware Workstation 12 Player. growingthe starting during size theof the experiments, images were but under remained 1GB. under (They 3GB.) were reasons:reasons: They were executed by VMware Workstation 12 Player. The licenses of certain vendors (e.g. [27] and [28]) do Tablegrowing 1 shows during the the Linux experiments, and WMware but remained settings underused fo3GB.)r the reasons: The licenses of certain vendors (e.g. [27] and [28]) do growing during the experiments, but remained under 3GB.) ThenotThe allowlicenseslicenses reverse ofof certaincertain engineering vendorsvendors and (e.g.(e.g. sometimes [27][27] andand [28]even[28])) th do doe We propose the structure of a simple testbed suitable for the virtualTable 1machines. shows the Linux and WMware settings used for the Thenot allowlicenses reverse of certain engineering vendors and (e.g. sometimes [27] and even[28]) th doe Table 1 shows the Linux and WMware settings used for the notnotpublication allowallow reversereverse of benchmarking engineeringengineering results andand sometimessometimes is prohibited. eveneven ththee We propose the structure of a simple testbed suitable for the virtual machines. notpublication allow reverse of benchmarking engineering results and sometimes is prohibited. even the securityWe propose analysis the of structure the DNS64 of a andsimple the testbed stateful suitab NATle64 for IPv6 the virtualWe note machines. that the IP version between the client, which is an publicationFreepublication software ofof benchmarkingbenchmarkingcan be used by resultsresults anyone isis prohibited.prohibited.for any purpose s security analysis of the DNS64 and the stateful NAT64 IPv6 publicationFree software of benchmarkingcan be used by results anyone is prohibited.for any purpose s transitionsecurity analysis technologies. of the SimilarDNS64 testbedsand the stateful can be NAT built 64 for IPv6 the IPv6onlyWe note client, that the and IP the version DNS64 between server mustthe client, be 6. Twhiherech isis noan Free software can be used by anyone for any purposes We note that the IP version between the client, which is an FreethusFree softwareoursoftware results cancan can bebe be usedused helpful byby anyoneforanyone anyone. forfor anyany purposepurposess securitytransition analysis technologies. of other SimilarIPv6 transition testbeds technolo can be gies. built for the IPv6only client, and the DNS64 server must be 6. There is no 6 Freethus oursoftware results can can be be used helpful by foranyone anyone. for any purposes transition technologies. Similar testbeds can be built for the restrictionIPv6only forclient, the IPand version the DNS64 between server the mustDNS64 be se6.rver There and is the no In this section, we demonstrate the correct operation of the thusFreethus ouroursoftware resultsresults is cancan available bebe helpfulhelpful free forforof charge anyone.anyone. for us, too. security analysis of other IPv6 transition technologies. Fig. 4. Wireshark capture taken during the functionIn althis checking section, of the we DNS64 demonstrate testbed. the correct operation of the thusFree oursoftware results is can available be helpful free forof chargeanyone. for us, too. securityThe testing analysis of DNS64of other or IPv6 NAT64 transition requires technolo a networkgies. of three DNSrestriction server, for butthe IP when version testing between NAT64, the DNS64 IPv4 must server be and us theed testInIn system, thisthis section,section, and also wewe introduce demonstratedemonstrate the theoperationthe correctcorrect of operati operatiDNS64onon servers, ofof thethe >Within REPLACEFreeFree the softwaresoftware category THIS isis LINE of availableavailable the WITH free free freesoftware YOUR ofof chargecharge implementa PAPER forfor us, us,IDENTIFICATION ttions,too.oo. we NUMBER (DOUBLECLICK HERE TO EDIT) < The testing of DNS64 or NAT64 requires a network of three testIn system, this section, and also we introduce demonstrate the operationthe correct of operati DNS64on servers, of the Within Free the software category is ofavailable the free freesoftware of charge implementa for us, tions,too. we The testing of DNS64 or NAT64 requires a network of three DNS server, but when testing NAT64, IPv4 must be used testtest system, system, andand also also introduce introduce the the operation operation ofof DNDNS64S64 servers, servers, WithinWithin the the category category of of the the free free software software implementa implementations,tions, we we between the NAT64 gateway and the IPv4only server. whichtest system, will be and important also introduce later. the operation of DNS64 servers, giveWithin further the priority category to those,of the freewhich software are used implementa widespreadtions, and/or we experiments with the other DNS64 implementations. Although we used IPv4 between the DNS64 server and the We tested the operation of the testbed by issuing the are known to be stable and high performance (if such As for its configuration, we have added the following lines authoritative DNS server during our DNS64 vulnerability tests, following command on the computer: information is available).” [2] to the file: we set also an IPv6 address at the authoritative DNS server to Although several DNS implementations exist, only very few of them can do DNS64, thus finding such DNS64 be able to reach it directly from the client for testing its JUNE 2018 • VOLUME X • NUMBER 2 17 operability. The Linux command was used to request a AAAA implementations was not an easy task. We selected the following DNS64 implementations for testing: We also note that the interfaces were not necessary for record for the domain name from the the tests, we used them for providing the virtual machines with 1. BIND 9.9.59+deb8u12Debian [24] DNS64 server executed by the host named . Internet access, which was sometimes necessary, e.g. for 2. TOTD 1.5.2 (referred later as OLDTOTD) [29] The DNS messages were captured by on the installing various packages under Debian Linux. We have 3. TOTD 1.5.3 (referred later as NEWTOTD) [30] interface using the capture filter. The six separated this communication from the testing communication, 4. mtd64ng 1.1.0 [31] captured packets are shown in Fig. 4. Now we shall identify the VI. TRANSACTION ID PREDICTION VULNERABILITY which happened always through the interfaces of the 5. PowerDNS Recursor 3.6.2 [32] six messages and observe their Transaction IDs, which are used TESTING virtual computers. 6. Unbound 1.6.0 [33] to match the answer with the query. We will experiment with Remarks: them later. Including BIND9 was a must as it is the de facto industry 1. Request for a AAAA record from the client to the We extended the configuration of our testbed to be able to The purpose of this setup was to check whether the testbed standard DNS server, therefore, it is very likely wide DNS64 server with Transaction ID 0x7c4a, generated by examine the Transaction IDs of a high number of messages works properly. We have installed BIND9 [24] to both the spread used for DNS64 purposes, too. the command. Some years before we have prepared a patch for TOTD, even if the examined DNS64 implementations use caching. and the virtual machines. 2. Request for a AAAA record from the DNS64 server to which resolved some security issues [30], and now we the authoritative DNS server with a different Transaction tested its both patched and unpatched versions. To be able to perform a high number of tests, we needed a The file was used ID, 0xcad0, generated by BIND. We also have a new tiny DNS64 proxy called mtd64ng name space which can be generated systematically. We have to set up the DNS64 function. The relevant settings were: 3. An “empty” reply for the AAAA record request sent by [31], which is currently developed in an ongoing found that the name space used in our earlier DNS64 tests [34] the authoritative DNS server to the DNS64 server, and university project. Although it is not yet ready for would be appropriate. It was the following name space: its Transaction ID is the same as that of the deployment, we have also included it. 10abc.dns64perf.test, where a, b, c are integers from the corresponding request. We have already introduced the DNS64 configuration of [0, 255] interval. 4. Request for an A record from the DNS64 server to the BIND in section IV.D.1. We have used only the 100{0..255}{0..225} part of it. For authoritative DNS server with a different Transaction ID, The file was used to The configuration of both versions of TOTD was done in the generating the zone file, we used the modified version of the 0xee9d, generated by BIND. set up the authoritative DNS server. The relevant settings were: zone file generator script called , which is 5. A valid reply with an A record sent by the authoritative file, the relevant settings were: shipped together with the program (documented DNS server to the DNS64 server, and its Transaction ID in [34] and available from [35]). is the same as that of the corresponding request. 6. The reply of the DNS64 server to the client containing The file of the authoritative DNS server was modified as follows: the synthesized [12] with The configuration of the mtd64ng DNS proxy was done in The content of the file was: the same Transaction ID as message 1. the file, where the relevant settings Thus we have found that the testbed worked fine, and it was were: ready for testing. V. DNS64 IMPLEMENTATION SELECTION AND SETUP Thus, BIND used our newly generated zone file after its We have laid down our implementations selection guidelines being restarted. The DNS64 configuration of PowerDNS was a bit more in [2] as follows: complex. “As for the implementations, we only deal with those that are The measurements were performed by the [34] In the file, we made free software [25] (also called open source [26]) for multiple program, which used sequential Transaction IDs from 0 to the following relevant settings: reasons: 65535. The command line of the test program was: The licenses of certain vendors (e.g. [27] and [28]) do not allow reverse engineering and sometimes even the publication of benchmarking results is prohibited. The first argument specified the “a” parameter described Free software can be used by anyone for any purposes above, the second argument meant that the test program needed thus our results can be helpful for anyone. The content of the file to use only one thread, the third one specified the timeout of 1 In this section, we demonstrate the correct operation of the Free software is available free of charge for us, too. was: second, and the last one was the host name of the DNS64 server to be tested. test system, and also introduce the operation of DNS64 servers, Within the category of the free software implementations, we The traffic was captured by the program executed by the host, the memory size of which was raised to 256MB, because 128MB was not enough and the program exited during the measurement. All the packets from As for Unbound, its 1.4.22 version distributed in Debian 8.9 did not contain the DNS64 module, which was included from the interface that matched the capture filter its next version, namely 1.5.0. Therefore we upgraded the were saved to a file. The following command line was used: host to Debian 9.3 after the execution of all the 7 INFOCOMMUNICATIONS JOURNAL 6 7> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Methodology6 for DNS Cache Poisoning Vulnerability >6 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >7 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Analysis> REPLACE of DNS64 THIS ImplementationsLINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
give further priority to those, which are used widespread and/or experiments with the other DNS64 implementations. give further priority to those, which are used widespread and/or experiments with the other DNS64 implementations. aregive knownfurther priority to be to stable those, andwhich high are used performance widespread (if and/or such experimentsAs for its withconfiguration, the other DNS64we have implementations. added the followi ng lines are known to be stable and high performance (if such As for its configuration, we have added the following lines information is available).” [2] to the file: information is available).” [2] to the file: informationAlthough isseveral available).” DNS implementations [2] exist, only very few to the file: Although several DNS implementations exist, only very few of Although them can several do DNS DNS64, implementations thus finding exist, suchonly ve DNS64ry few of them can do DNS64, thus finding such DNS64 of them can do DNS64, thus finding such DNS64 implementations was not an easy task. We selected the implementations was not an easy task. We selected the implementationsfollowing DNS64 wasimplementations not an easy for task.testing: We selected the following DNS64 implementations for testing: following DNS64 implementations for testing: following1. BIND DNS64 9.9.59+deb8u12Debian implementations for [24]testing: 1. BIND 9.9.59+deb8u12Debian [24] 1. BIND 9.9.59+deb8u12Debian [24] 2. TOTD 1.5.2 (referred later as OLDTOTD) [29] 2. TOTD 1.5.2 (referred later as OLDTOTD) [29] 2.3. TOTD 1.5.21.5.3 (referred later as OLDTOTD)NEWTOTD) [29][30] 3. TOTD 1.5.3 (referred later as NEWTOTD) [30] 3.4. TOTDmtd64ng 1.5.3 1.1.0 (referred [31] later as NEWTOTD) [30] 4. mtd64ng 1.1.0 [31] VI. TRANSACTION ID PREDICTION VULNERABILITY 4.5. mtd64ngPowerDNS 1.1.0 Recursor [31] 3.6.2 [32] VI. TRANSACTION ID PREDICTION VULNERABILITY 5. PowerDNS Recursor 3.6.2 [32] VI. TRANSACTION ID PREDICTION VULNERABILITY 5.6. PowerDNSUnbound 1.6.0 Recursor [33] 3.6.2 [32] TESTING 6. Unbound 1.6.0 [33] TESTING 6.Remarks: Unbound 1.6.0 [33] 7 TESTING Remarks: Remarks: Including BIND9 was a must as it is the de facto industry > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Including BIND9 was a must as it is the de facto industry We extended the configuration of our testbed to be able to Includingstandard DNS BIND9 server, was atherefore, must as it itis isthe very de facto likely in dustrywide We extended the configuration of our testbed to be able to standard DNS server, therefore, it is very likely wide We extended the configuration of our testbed to be able to standardspread used DNS for server, DNS64 therefore, purposes, it too. is very likely wide examine the Transaction IDs of a high number of messages spread used for DNS64 purposes, too. examine the Transaction IDs of a high number of messages spreadSome years used beforefor DNS64 we have purposes, prepared too. a patch for TOTD, even if the examined DNS64 implementations use caching. Some years before we have prepared a patch for TOTD, even if the examined DNS64 implementations use caching. Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) Somewhich yearsresolved before some we securityhave prepared issues a[30], patch and for now TOTD we, which resolved some security issues [30], and now we Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) whichtested itsresolved both patched some security and unpatched issues [30],versions. and now we To be able to perform a high number of tests, we needed a tested its both patched and unpatched versions. To be able to perform a high number of tests, we needed a Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) testedWe also its have both apatched new tiny and DNS64 unpatched proxy versions. called mtd64ng name space which can be generated systematically. We have We also have a new tiny DNS64 proxy called mtd64ng name space which can be generated systematically. We have We[31], also which have a is new currently tiny DNS64 developed proxy called in an mtd64ng ongoing foundname spacethat the which name can space be usedgenerated in our systematically.earlier DNS64 testsWe have[34] [31], which is currently developed in an ongoing found that the name space used in our earlier DNS64 tests [34] [31],university which project. is currently Although developed it is not in yet an ready ongoing for wouldfound thatbe appropriate. the name space It was used the in following our earlier name DNS64 space: tests [34] university project. Although it is not yet ready for would be appropriate. It was the following name space: universitydeployment, project. we have Although also included it is it. not yet ready for would10abc.dns64perf.test, be appropriate. It was where the following a, b, c are name integers space: from the deployment, we have also included it. 10abc.dns64perf.test, where a, b, c are integers from the We deployment, have already we introduced have also theincluded DNS64 it. configuration of [0,10abc.dns64perf.test, 255] interval. where a, b, c are integers from the We have already introduced the DNS64 configuration of [0, 255] interval. BINDWe in have section already IV.D.1. introduced the DNS64 configuration of [0,We 255] have interval. used only the 100{0..255}{0..225} part of it. For BIND in section IV.D.1. We have used only the 100{0..255}{0..225} part of it. For BINDThe inconfiguration section IV.D.1. of both versions of TOTD was done in the generatingWe have theused zone only file, the 100{0..255}{0..225}we used the modified vers partion of it.of Forthe The configuration of both versions of TOTD was done in the generating the zone file, we used the modified version of the The configuration of both versions of TOTD was done in the zonegenerating file generator the zone scriptfile, we called used the modified vers,ion which of the is file, the relevant settings zone file generator script called , which is file, the relevant settings zone file generator script called , which is were: shipped together with the program (documented were: shipped together with the program (documented were: inshipped [34] and together available with from the [35]). program (documented in [34] and available from [35]). in The[34] and available from [35]). file of the The file of the authoritativeThe DNS server was modified as follows: file of the The configuration of the mtd64ng DNS proxy was done in authoritative DNS server was modified as follows: The configuration of the mtd64ng DNS proxy was done in authoritative DNS server was modified as follows: theThe configuration of the mtd64ng file, where DNS the proxy relevant was settingsdone in the file, where the relevant settings the file, where the relevant settings were: were: Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) were: Thus, BIND used our newly generated zone file after its Thus, BIND used our newly generated zone file after its beingThus, restarted. BIND used our newly generated zone file after its being restarted. The DNS64 configuration of PowerDNS was a bit more being restarted. Fig. 6. OLDTOTD, Transaction ID input correlation (left) and autocorrelation (right) The DNS64 configuration of PowerDNS was a bit more complex.The DNS64 configuration of PowerDNS was a bit more The measurements were performed by the [34] Fig. 6. OLDTOTD, Transaction ID input correlation (left) and autocorrelation (right) complex. The measurements were performed by the [34] complex.In the file, we made The measurements were performed by the [34] Fig. 6. OLDTOTD, Transaction ID input correlation (left) and autocorrelation (right) In the file, we made program, which used sequential Transaction IDs from 0 to where the string was replaced by the name of the tested method is more thorough than that. theIn following the relevant settings: file, we made program, which used sequential Transaction IDs from 0 to the following relevant settings: 65535.program, The which command used line sequential of the test Transaction program was: IDs from 0 to DNS64where implementation. the string was replaced by the name of the tested methodWe is have more checked thorough twothan that. kinds of correlations using the following relevant settings: 65535. The command line of the test program was: DNS64where implementation. the string was replaced by the name of the tested methodvisualization.We is have more Before checked thorough introducing twothan that. kinds them, of let correlations us define usingsome notations first. Let denote the ordinal number of a message in DNS64 implementation. visualization.We have Before checked introducing two kinds them, of let correlations us define usingsome The first argument specified the “a” parameter described Predictability of the Transaction IDs is a hard question. E.g. The first argument specified the “a” parameter described notationsvisualization.the message first. sequence BeforeLet denote introduced introducing the ordinal in them, section number let IV.E, us of defiawh messageerene some is in The first argument specified the “a” parameter described if pseudorandom numbers are used that were generated by a above, the second argument meant that the test program needed Predictability of the Transaction IDs is a hard question. E.g. notationsthe[1, 6].message Let first. sequencedenote Let denotethe introduced ordinal the ordinal number in section number of theIV.E, of AAAA awh messageere record is in above, the second argument meant that the test program needed The content of the file toabove, use onlythe second one thread, argument the third meant one that specified the test theprog timeoutram needed of 1 iflinear pseudorandomPredictability congruential of numbers thegenerator Transaction are (LCG), used IDs thatthen is wereathey hard aregenerate que predictable.stion.d byE.g. a request sent by the program, where is in [0, The content of the file to use only one thread, the third one specified the timeout of 1 the[1, 6].message Let sequencedenote the introduced ordinal number in section of theIV.E, AAAA where record is in was:The content of the file second,to use only and onethe lastthread, one thewas third the host one namespecified of the the D timeoutNS64 server of 1 iflinearThere pseudorandom congruential are a high numbers numbergenerator are of (LCG), methodsused thatthen described werethey aregenerate predictable. for d te sting by a was: second, and the last one was the host name of the DNS64 server [1,65535].request 6]. Let sentLet denote by denote the the the ordinal Transaction number program, ID of of the wherethe AAAA th message is record in [0, was: tosecond, be tested. and the last one was the host name of the DNS64 server linearThererandomness congruential are a both high in numbergenerator university of (LCG), lecture methods then notes described they [36] are an predictable. ford research testing to be tested. from65535].request the sentLet six by messages denote the the used Transaction to resolve program, ID the of whereththe queryth message is of in the [0, to be tested. papers [37]. The traffic was captured by the program executed Thererandomness are a both high in number university of lecture methods notes described [36] an ford research testing program. As the test program uses sequential The traffic was captured by the program executed from65535]. the Let six messages denote the used Transaction to resolve ID the of ththe queryth message of the by The the traffic was host, captured the memory by the size of which program was executedraised to papersrandomnessSince [37]. our bothsolution in university of using alecture testbed notes ensures [36] us an fudll research control by the host, the memory size of which was raised to fromTransaction the six IDs messages program. from 0, usedit As is thesure to testresolvethat: program the= th uses= query. sequential of the by the host, the memory size of which was raised to of the testing method, and gives us access to the raw results, we 256MB, because 128MB was not enough and the papersSince [37]. our solution of using a testbed ensures us full control We use two graphs. An (x, y) plot of the (, ) pairs may 256MB, because 128MB was not enough and the Transaction IDs program. from 0, it As is thesure testthat: program = uses= . sequential 256MB, because 128MB was not enough and the ofhave Sincethe the testing ourpossibility solution method, to ofand use using gives multiple a ustestbed access methods ensures to the for rusaw ev fu results,aluationll control we if program exited during the measurement. All the packets from revealTransactionWe use correlation two IDs graphs. from between 0, An it is(x, sure the y) plot Transactionthat: of the = ( ID =, . used ) pairs by may the As for Unbound, its 1.4.22 version distributed in Debian 8.9 program exited during the measurement. All the packets from needed. We decided to use first a simple, graphical method, As for Unbound, its 1.4.22 version distributed in Debian 8.9 theprogram exited interface during that the matched measurement. the All the packcaptureets fromfilter ofhave the the testing possibility method, to and use gives multiple us access methods to the for raw ev results,aluation we if program and the first Transaction ID generated didAs not for contain Unbound, the DNS64its 1.4.22 module, version which distributed was include in Debiand from 8.9 the interface that matched the capture filter revealWe use correlation two graphs. between An (x, the y) plot Transaction of the ( ID, used) pairs by may the did not contain the DNS64 module, which was included from thewere saved interface to a file. thatThe matchedfollowing the command line capturewas used: filter needed.havewhich the is We possibility somewhat decided to similarto use use multiple firstto that a simple,methods of the graphical earlier for ev mealuation method,ntioned if 6 itsdid nextnot contain version, the namely DNS64 1.5.0. module, Therefore which was we include upgradded from the were saved to a file. The followingFig. 6. commandOLDTOTD, lineTransaction was used: ID input correlation (left) and autocorrelation (right) byreveal the DNS64 correlation programprogram. between and An (x,the the y) first Transactionplot Transaction of the ( ID, ID used) pairsgenerated by may the its next version, namely 1.5.0. Therefore we upgraded the were saved to a file. The following command line was used: needed.whichentropy is testerWe somewhat decided of DNSOARC similarto use firstto [19], that a simple, of but the we graphical earlier contend me thamethod,ntionedt our > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATIONits next NUMBER host version, to (DOUBLECLICK Debian namely 9.3 1.5.0. after Therefore theHERE execution TO we EDIT) upgrad of < alled the by the DNS64 programprogram. and An (x,the y) first plot Transaction of the (, ID) pairsgenerated may host to Debian 9.3 after the execution of all the whichentropy is tester somewhat of DNSOARC similar to [19], that of but the we earlier contend me thantionedt our host to Debian 9.3 after the execution of all the by the DNS64 program. An (x, y) plot of the (, ) pairs may where the string was replaced by the name of the tested method is more thoroughentropy than tester that. of DNSOARC [19], but we contend that our give further priority to those, which are used widespread and/or experiments with the other DNS64 implementations. DNS64 implementation. We have checked two kinds of correlations using are known to be stable and high performance (if such As for its configuration, we have added the following lines visualization. Before introducing them, let us define some information is available).” [2] to the file: notations first. Let denote the ordinal number of a message in Although several DNS implementations exist, only very few Predictability of the Transaction IDs is a hard question. E.g. the message sequence introduced in section IV.E, where is in of them can do DNS64, thus finding such DNS64 if pseudorandom numbers are used that were generated by a [1, 6]. Let denote the ordinal number of the AAAA record implementations was not an easy task. We selected the 18 linear congruential generator (LCG),JUNE 2018 then •they VOLUME are Xpredictable. • NUMBER 2 request sent by the program, where is in [0, There are a high number of methods described for testing following DNS64 implementations for testing: 65535]. Let denote the Transaction ID of the th message 1. BIND 9.9.59+deb8u12Debian [24] randomness both in university lecture notes [36] and research from the six messages used to resolve the th query of the 2. TOTD 1.5.2 (referred later as OLDTOTD) [29] papers [37]. program. As the test program uses sequential 3. TOTD 1.5.3 (referred later as NEWTOTD) [30] Since our solution of using a testbed ensures us full control Transaction IDs from 0, it is sure that: = = . 4. mtd64ng 1.1.0 [31] of the testing method, and gives us access to the raw results, we We use two graphs. An (x, y) plot of the (, ) pairs may 5. PowerDNS Recursor 3.6.2 [32] VI. TRANSACTION ID PREDICTION VULNERABILITY have the possibility to use multiple methods for evaluation if reveal correlation between the Transaction ID used by the 6. Unbound 1.6.0 [33] TESTING needed. We decided to use first a simple, graphical method, program and the first Transaction ID generated Remarks: which is somewhat similar to that of the earlier mentioned by the DNS64 program. An (x, y) plot of the (, ) pairs may Including BIND9 was a must as it is the de facto industry entropy tester of DNSOARC [19], but we contend that our We extended the configuration of our testbed to be able to standard DNS server, therefore, it is very likely wide spread used for DNS64 purposes, too. examine the Transaction IDs of a high number of messages Some years before we have prepared a patch for TOTD, even if the examined DNS64 implementations use caching. which resolved some security issues [30], and now we tested its both patched and unpatched versions. To be able to perform a high number of tests, we needed a We also have a new tiny DNS64 proxy called mtd64ng name space which can be generated systematically. We have [31], which is currently developed in an ongoing found that the name space used in our earlier DNS64 tests [34] university project. Although it is not yet ready for would be appropriate. It was the following name space: deployment, we have also included it. 10abc.dns64perf.test, where a, b, c are integers from the We have already introduced the DNS64 configuration of [0, 255] interval. BIND in section IV.D.1. We have used only the 100{0..255}{0..225} part of it. For The configuration of both versions of TOTD was done in the generating the zone file, we used the modified version of the zone file generator script called , which is file, the relevant settings were: shipped together with the program (documented in [34] and available from [35]). The file of the authoritative DNS server was modified as follows: The configuration of the mtd64ng DNS proxy was done in the file, where the relevant settings were: Thus, BIND used our newly generated zone file after its being restarted. The DNS64 configuration of PowerDNS was a bit more complex. The measurements were performed by the [34] In the file, we made program, which used sequential Transaction IDs from 0 to the following relevant settings: 65535. The command line of the test program was: The first argument specified the “a” parameter described above, the second argument meant that the test program needed The content of the file to use only one thread, the third one specified the timeout of 1 was: second, and the last one was the host name of the DNS64 server to be tested. The traffic was captured by the program executed by the host, the memory size of which was raised to 256MB, because 128MB was not enough and the program exited during the measurement. All the packets from As for Unbound, its 1.4.22 version distributed in Debian 8.9 did not contain the DNS64 module, which was included from the interface that matched the capture filter its next version, namely 1.5.0. Therefore we upgraded the were saved to a file. The following command line was used: host to Debian 9.3 after the execution of all the 7 7 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < INFOCOMMUNICATIONS> REPLACE THIS LINE JOURNAL WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 6 7 6 Methodology for DNS Cache Poisoning Vulnerability >6 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >7 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Analysis of DNS64 Implementations > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < give further priority to those, which are used widespread and/or experiments with the other DNS64 implementations. give further priority to those, which are used widespread and/or experiments with the other DNS64 implementations. aregive knownfurther priority to be to stable those, andwhich high are used performance widespread (if and/or such experimentsAs for its withconfiguration, the other DNS64we have implementations. added the followi ng lines are known to be stable and high performance (if such As for its configuration, we have added the following lines information is available).” [2] to the file: information is available).” [2] to the file: informationAlthough isseveral available).” DNS implementations [2] exist, only very few to the file: Although several DNS implementations exist, only very few of Although them can several do DNS DNS64, implementations thus finding exist, suchonly ve DNS64ry few of them can do DNS64, thus finding such DNS64 of them can do DNS64, thus finding such DNS64 implementations was not an easy task. We selected the implementations was not an easy task. We selected the followingimplementations DNS64 wasimplementations not an easy for task.testing: We selected the following DNS64 implementations for testing: following DNS64 implementations for testing: following1. BIND DNS64 9.9.59+deb8u12Debian implementations for [24]testing: 1. BIND 9.9.59+deb8u12Debian [24] 1. BIND 9.9.59+deb8u12Debian [24] 2. TOTD 1.5.2 (referred later as OLDTOTD) [29] 2. TOTD 1.5.2 (referred later as OLDTOTD) [29] 2.3. TOTD 1.5.21.5.3 (referred later as OLDTOTD)NEWTOTD) [29][30] 3. TOTD 1.5.3 (referred later as NEWTOTD) [30] 3.4. TOTDmtd64ng 1.5.3 1.1.0 (referred [31] later as NEWTOTD) [30] 4. mtd64ng 1.1.0 [31] VI. TRANSACTION ID PREDICTION VULNERABILITY 4.5. mtd64ngPowerDNS 1.1.0 Recursor [31] 3.6.2 [32] VI. TRANSACTION ID PREDICTION VULNERABILITY 8 5. PowerDNS Recursor 3.6.2 [32] VI. TRANSACTION ID PREDICTION VULNERABILITY 5.6. PowerDNSUnbound 1.6.0 Recursor [33] 3.6.2 [32] 7 TESTING > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 6. Unbound 1.6.0 [33] TESTING 6.Remarks: Unbound 1.6.0 [33] > REPLACETESTING THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Remarks: Remarks: Including BIND9 was a must as it is the de facto industry Including BIND9 was a must as it is the de facto industry We extended the configuration of our testbed to be able to standardIncluding DNS BIND9 server, was atherefore, must as it itis isthe very de facto likely in dustrywide We extended the configuration of our testbed to be able to standard DNS server, therefore, it is very likely wide We extended the configuration of our testbed to be able to spreadstandard used DNS for server, DNS64 therefore, purposes, it too. is very likely wide examine the Transaction IDs of a high number of messages spread used for DNS64 purposes, too. examine the Transaction IDs of a high number of messages Somespread years used beforefor DNS64 we have purposes, prepared too. a patch for TOTD, even if the examined DNS64 implementations use caching. Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) Some years before we have prepared a patch for TOTD, even if the examined DNS64 implementations use caching. Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) whichSome yearsresolved before some we securityhave prepared issues a[30], patch and for now TOTD we, which resolved some security issues [30], and now we Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) testedwhich itsresolved both patched some security and unpatched issues [30],versions. and now we To be able to perform a high number of tests, we needed a tested its both patched and unpatched versions. To be able to perform a high number of tests, we needed a Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) Wetested also its have both apatched new tiny and DNS64 unpatched proxy versions. called mtd64ng name space which can be generated systematically. We have We also have a new tiny DNS64 proxy called mtd64ng name space which can be generated systematically. We have [31],We also which have a is new currently tiny DNS64 developed proxy called in an mtd64ng ongoing foundname spacethat the which name can space be usedgenerated in our systematically.earlier DNS64 testsWe have[34] [31], which is currently developed in an ongoing found that the name space used in our earlier DNS64 tests [34] university[31], which project. is currently Although developed it is not in yet an ready ongoing for wouldfound thatbe appropriate. the name space It was used the in following our earlier name DNS64 space: tests [34] university project. Although it is not yet ready for would be appropriate. It was the following name space: deployment,university project. we have Although also included it is it. not yet ready for would10abc.dns64perf.test, be appropriate. It was where the following a, b, c are name integers space: from the deployment, we have also included it. 10abc.dns64perf.test, where a, b, c are integers from the We deployment, have already we introduced have also theincluded DNS64 it. configuration of [0,10abc.dns64perf.test, 255] interval. where a, b, c are integers from the We have already introduced the DNS64 configuration of [0, 255] interval. BINDWe in have section already IV.D.1. introduced the DNS64 configuration of [0,We 255] have interval. used only the 100{0..255}{0..225} part of it. For BIND in section IV.D.1. We have used only the 100{0..255}{0..225} part of it. For BINDThe inconfiguration section IV.D.1. of both versions of TOTD was done in the generatingWe have theused zone only file, the 100{0..255}{0..225}we used the modified vers partion of it.of Forthe The configuration of both versions of TOTD was done in the generating the zone file, we used the modified version of the The configuration of both versions of TOTD was done in the zonegenerating file generator the zone scriptfile, we called used the modified vers,ion which of the is file, the relevant settings zone file generator script called , which is file, the relevant settings zone file generator script called , which is were: shipped together with the program (documented were: shipped together with the program (documented were: inshipped [34] and together available with from the [35]). program (documented in [34] and available from [35]). in The[34] and available from [35]). file of the The file of the The file of the authoritative DNS server was modified as follows: The configuration of the mtd64ng DNS proxy was done in authoritative DNS server was modified as follows: The configuration of the mtd64ng DNS proxy was done in authoritative DNS server was modified as follows: Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) theThe configuration of the mtd64ng file, where DNS the proxy relevant was settingsdone in the file, where the relevant settings Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelation (right) the file, where the relevant settings were: were: were: Thus, BIND used our newly generated zone file after its Thus, BIND used our newly generated zone file after its beingThus, restarted. BIND used our newly generated zone file after its being restarted. Fig. 6. OLDTOTD, Transaction ID input correlation (left) and autocorrelation (right) The DNS64 configuration of PowerDNS was a bit more being restarted. Fig. 6. OLDTOTD, Transaction ID input correlation (left) and autocorrelation (right) The DNS64 configuration of PowerDNS was a bit more complex.The DNS64 configuration of PowerDNS was a bit more The measurements were performed by the [34] Fig. 6. OLDTOTD, Transaction ID input correlation (left) and autocorrelation (right) complex. The measurements were performed by the [34] complex.In the file, we made The measurements were performed by the [34] where the string was replacedFig. 6. OLDTOTD, by the name Transaction of the IDtested input correlationmethod (left) is more and autocorrelation thorough than (right) that. In the file, we made program, which used sequential Transaction IDs from 0 to where the string was replaced by the name of the tested method is more thorough than that. theIn following the relevant settings: file, we made program, which used sequential Transaction IDs from 0 to DNS64 implementation. We have checked two kinds of correlations using the following relevant settings: 65535.program, The which command used line sequential of the test Transaction program was: IDs from 0 to DNS64where implementation. the string was replaced by the name of the tested methodWe is have more checked thorough twothan that. kinds of correlations using the following relevant settings: 65535. The command line of the test program was: visualization. Before introducing them, let us define some DNS64where implementation. the string was replaced by the name of the tested methodvisualization.We is have more Before checked thorough introducing twothan that. kinds them, of let correlations us define usingsome notations first. Let denote the ordinal number of a message in notations first. Let denote the ordinal number of a message in DNS64Predictability implementation. of the Transaction IDs is a hard question. E.g. visualization.We have Before checked introducing two kinds them, of let correlations us define usingsome The first argument specified the “a” parameter described Predictability of the Transaction IDs is a hard question. E.g. the message sequence introduced in section IV.E, where is in The first argument specified the “a” parameter described notationsvisualization.the message first. sequence BeforeLet denote introduced introducing the ordinal in them, section number let IV.E, us of defiawh messageerene some is in The first argument specified the “a” parameter described if pseudorandom numbers are used that were generated by a [1, 6]. Let denote the ordinal number of the AAAA record above,The the first second argument argument specified meant the that “a” the parametertest program desc neededribed if pseudorandomPredictability of numbers the Transaction are used IDs that is werea hard generate question.d byE.g. a [1, 6]. Let denote the ordinal number of the AAAA record above, the second argument meant that the test program needed linear congruential generator (LCG), then they are predictable. notationsthe message first. sequence Let denote introduced the ordinal in section number IV.E, of awh messageere is in The content of the file toabove, use onlythe second one thread, argument the third meant one that specified the test theprog timeoutram needed of 1 iflinear pseudorandomPredictability congruential of numbers thegenerator Transaction are (LCG), used IDs thatthen is wereathey hard aregenerate que predictable.stion.d byE.g. a request sent by the program, where is in [0, The content of the file to use only one thread, the third one specified the timeout of 1 There are a high number of methods described for testing the[1,request 6].message Let sent sequencedenote by the the introduced ordinal number in program, section of theIV.E, where AAAA wh ere is record in is [0,in was:The content of the file second,to use only and onethe lastthread, one thewas third the host one namespecified of the the D timeoutNS64 server of 1 There are a high number of methods described for testing 65535]. Let denote the Transaction ID of the th message was: second, and the last one was the host name of the DNS64 server iflinear pseudorandom congruential numbers generator are (LCG), used thatthen werethey aregenerate predictable.d by a [1,request65535]. 6]. Let sentLet denote by denote the the the ordinal Transaction number program, ID of of the wherethe AAAA th message is record in [0, was: second, and the last one was the host name of the DNS64 server randomness both in university lecture notes [36] and research from the six messages used to resolve the th query of the tosecond, be tested. and the last one was the host name of the DNS64 server linearThererandomness congruential are a both high in numbergenerator university of (LCG), lecture methods then notes described they [36] are an predictable. ford research testing from the six messages used to resolve the th query of the to be tested. papers [37]. 65535].request sentLet by denote the the Transaction program, ID of wherethe th message is in [0, to Thebe tested. traffic was captured by the program executed papersThererandomness are[37]. a both high in number university of lecture methods notes described [36] an ford research testing program. As the test program uses sequential The traffic was captured by the program executed Since our solution of using a testbed ensures us full control from65535]. the Let six messages program. denote the used As Transaction the to testresolve program ID the of ththe uses queryth sequential message of the The traffic was captured by the program executed Since our solution of using a testbed ensures us full control Transaction IDs from 0, it is sure that: = = . by the host, the memory size of which was raised to papersrandomness [37]. both in university lecture notes [36] and research Transaction IDs from 0, it is sure that: = = . by the host, the memory size of which was raised to of the testing method, and gives us access to the raw results, we from the six messages program. used As the to testresolve program the th uses query sequential of the 256MB,by the because host, 128MB the memory was not size enough of which and was the raised to papersof Sincethe testing [37]. our solution method, ofand using gives a ustestbed access ensures to the rusaw fu results,ll control we We use two graphs. An (x, y) plot of the (, ) pairs may 256MB, because 128MB was not enough and the have the possibility to use multiple methods for evaluation if TransactionWe use two IDs program.graphs. from 0, An it As is(x, thesure y) plot testthat: of program the = ( uses=, . ) sequentialpairs may 256MB, because 128MB was not enough and the have the possibility to use multiple methods for evaluation if reveal correlation between the Transaction ID used by the program256MB, exited because during 128MB the wasmeasurement. not enough All andthe thepack ets from of Sincethe testing our solution method, ofand using gives a ustestbed access ensures to the rusaw fu results,ll control we reveal correlation between the Transaction ID used by the As for Unbound, its 1.4.22 version distributed in Debian 8.9 program exited during the measurement. All the packets from needed. We decided to use first a simple, graphical method, TransactionWe use two IDs graphs. from 0, An it is(x, sure y)Fig. plot that: 8. mtd64ng, of the = ( Transaction =, . ) pairs ID initial may correlatio n (left) and autocorrelation (right) As for Unbound, its 1.4.22 version distributed in Debian 8.9 theprogram exited interface during that the matched measurement. the All the packcaptureets fromfilter ofhaveneeded. the the testing Wepossibility decidedmethod, to toand use use gives multiple first us aaccess simple,methods to the graphical for raw ev results,aluation method, we if program and the first Transaction ID generated didAs not for contain Unbound, the DNS64its 1.4.22 module, version which distributed was include in Debiand from 8.9 the interface that matched the Fig. capture 6. OLDTOTD, filter Transaction ID input correlationwhich ( isleft) somewhat and autocorrelation similar (right) to that of the earlier mentioned revealWe use correlation two program graphs. between Anand (x, the the y) firstplot Transaction Transactionof the ( ID, ID used) pairsgenerated by may the did not contain the DNS64 module, which was included from the interface that matched the capture filter needed.havewhich the is We possibility somewhat decided to similarto use use multiple firstto that a simple,methods of the graphical earlier for ev mealuation method,ntioned if by the DNS64 program. An (x, y) plot of the (, ) pairs may itsdid nextnot contain version, the namely DNS64 1.5.0. module, Therefore which was we include upgradded from the were saved to a file. The following command line was used: entropy tester of DNSOARC [19], but we contend that our revealby the DNS64 correlation programprogram. between and An (x,the the y) first Transactionplot Transaction of the ( ID, ID used) pairsgenerated by may the its next version, namely 1.5.0. Therefore we upgraded the were saved to a file. The following command line was used: needed.whichentropy is testerWe somewhat decided of DNSOARC similarto use firstto [19], that a simple, of but the we graphical earlier contend me thamethod,ntionedt our reveal correlation between the consecutive Transaction IDs IDs. Before giving the explanation, let us have a look at the its next host version, to Debian namely 9.3 1.5.0. after Therefore the execution we upgrad of alled the by the DNS64 programprogram. and An (x,the y) first plot Transaction of the (, ID) pairsgenerated may host to Debian 9.3 after the execution of all the where the string was replaced by the name of the tested methodwhichentropy is is tester somewhatmore of thorough DNSOARC similar than to that. [19], that of but the we earlier contend me thantionedt our generated by the DNS64 program. For simplicity, we will refer autocorrelation of the Transaction IDs of OLDTOTD on the host to Debian 9.3 after the execution of all the by the DNS64 program. An (x, y) plot of the (, ) pairs may DNS64 implementation. entropyWe have tester ofchecked DNSOARC two kinds [19], but of we correlations contend tha usingt our to the first one as , and the second one as right side of Fig. 6. Now, the predictability is even more visualization. Before introducing them, let us define some . deliberate. Let us look into the CSV file containing the (, ) notations first. Let denote the ordinal number of a message in We used scripts to extract the appropriate Transaction pairs for input correlation checking: Predictability of the Transaction IDs is a hard question. E.g. the message sequence introduced in section IV.E, where is in IDs from the text file output of the program, and the 0, 55745 if pseudorandom numbers are used that were generated by a [1, 6]. Let denote the ordinal number of the AAAA record graphs were prepared by . 1, 56257 linear congruential generator (LCG), then they are predictable. request sent by the program, where is in [0, 2, 56769 There are a high number of methods described for testing JUNE 2018 • VOLUME X • NUMBER 2 65535]. Let denote the Transaction ID of the th message 19 3, 57281 randomness both in university lecture notes [36] and research from the six messages used to resolve the th query of the Fig. 5 shows the input correlation and the autocorrelation of 4, 57793 papers [37]. program. As the test program uses sequential the Transaction IDs of BIND. They seem to be like noise, thus Whereas the Transaction IDs start from 0 and increase by Since our solution of using a testbed ensures us full control Transaction IDs from 0, it is sure that: = = . we can say that no predictability problems were revealed by our 1, the Transaction IDs start from a different number and of the testing method, and gives us access to the raw results, we We use two graphs. An (x, y) plot of the (, ) pairs may simple evaluation method. increase by 512. The CSV file containing the (, ) pairs for have the possibility to use multiple methods for evaluation if reveal correlation between the Transaction ID used by the The left graph of Fig. 6 shows the input correlation of the autocorrelation checking can give us further help: needed. We decided to use first a simple, graphical method, program and the first Transaction ID generated Transaction IDs of OLDTOTD. The regular patterns indicate 55745, 56001 which is somewhat similar to that of the earlier mentioned by the DNS64 program. An (x, y) plot of the (, ) pairs may that there is a problem with the predictability of the Transaction 56257, 56513 entropy tester of DNSOARC [19], but we contend that our 8 >8 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < >8 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 9 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 9 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
8 INFOCOMMUNICATIONS JOURNAL Fig. 4.) Therefore, we had to make a new series of Table 2. Source Port Randomness Test Results Fig. 4.) Therefore, we had to make a new series of Methodology> REPLACE for THIS DNS LINE Cache WITH Poisoning YOUR PAPER Vulnerability IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Table 2. Source Port Randomness Test Results 8 9 measurements using a different command line for as Analysis of DNS64 Implementations source ports observed in the experiments > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACEDNS64 THISsource LINE ports WITH observed YOUR in the PAPER experiments IDENTIFICATION follows: NUMBERNUMBER (DOUBLECLICK(DOUBLECLICK HERE HERE TO TO EDIT) EDIT) < < Implementation Implementation minimum maximum std. dev. Fig. 4.) Therefore, we had to make a new series of BIND Table 2. Source1024 Port Randomness 65535 Test Results 18635 Fig. 4.) Therefore, we had to make a new series of Table 2. Source Port Randomness Test Results measurements using a different command line for as OLDTOTD 53 53 0 measurements using a different command line for as source ports observed in the experiments NEWTOTDDNS64 source 53 ports observed53 in the experiments0 follows:follows: NEWTOTDImplementation 53 53 0 The capture filter ensured that only IPv4 packets sent from Implementation minimum maximum std. dev. The capture filter ensured that only IPv4 packets sent from mtd64ng 32768 61000 8136 the DNS64 server program at (with source IP address BIND 1024 65535 18635 the DNS64 server program at (with source IP address PowerDNSBIND 10251024 6553465535 1865518635 PowerDNS 1025 65534 18655 10.0.0.2) to the authoritative DNS server program (listening at OLDTOTD 53 53 00 Unbound 1024 65535 17467 port 53 of ) be included. The output file contained only the NEWTOTD 53 53 00 sourceThe capture port numbers. filter ensured As expected, that only the IPv4 result packets files scontainedent from sourceThe capture port numbers. filter ensured As expected, that only the IPv4 result packets files containedsent from mtd64ng 32768 61000 8136 the131072 DNS64 numbers, server exceptprogram for at BIND, in (with the case source of whiIP addressch there 56769, 57025 the131072 DNS64 numbers, server exceptprogram for at BIND, in (withthe case source of whi IP chaddress there 8 56769,PowerDNS 57025 1025 65534 18655 10.0.0.2)were 131073 to the numbers authoritative in the DNSfile. We server have program investigat (listeninged the case at 57281,PowerDNS 57537 1025 65534 18655 10.0.0.2)were 131073 to the numbers authoritative in the file. DNS We server have program investigat (listeninged the case at > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 57281,Unbound 57537 1024 65535 17467 Unbound 1024 65535 17467 portand 53found of that) it be was included. so because The BINDoutput alsofile containedsent a query only for the the 7 57793, 58049 port 53 of ) be included. The output file contained only the 57793, 58049 sourceIP addresses port numbers. of the Asroot expected, DNS servers. the result None files of contained the other > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICKIt is well visible HEREthat the TO consecutive EDIT) < Transaction IDs always sourceIP addresses port numbers. of the root As expected, DNS servers. the result None files of contained the other It is well visible that the consecutive Transaction IDs always 131072implementations numbers, didexcept so. for BIND, in the case of which there Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) increase56769, by57025 256. And now we give the explanation. As we 131072implementations numbers, did except so. for BIND, in the case of which there Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) increase56769, by57025 256. And now we give the explanation. As we wereWe 131073 have numbers summarized in the file. our We results have investigat in Tableed 2. the BIND, case Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) disclosed57281, 57537 it in [30], the old version of TOTD generated wereWe 131073 have numbers summarized in the ourfile. We results have ininvestigat Table ed2. the BIND, case Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) disclosed57281, 57537 it in [30], the old version of TOTD generated andPowerDNS found that and it wasUnbound so because follow BIND the guidelinesalso sent a qofuery RFC for 5 the452 sequential57793, 58049numbers as Transaction IDs. The increase of 256 is andPowerDNS found that and it Unboundwas so because follow BIND the guidelines also sent a of query RFC for 5452 the sequential57793, 58049 numbers as Transaction IDs. The increase of 256 is IP[13] addresses and choose of a thesource root port DNS number servers. randomly None from of thethe largest other theIt result is well of visible the facts that that the theconsecutive notebook Transaction used for testing IDs always has an IP[13] addresses and choose of a source the root port DNS number servers. randomly None from of the the largest other theIt result is well of visible the facts that that the theconsecutive notebook Transaction used for testing IDs alwayshas an implementationsavailable range ofdid [1024, so. 65535]. Both versions of TOTD use Intelincrease CPU, by which 256. Anduses nowLSB webyte give order the (least explanation. significant As byte we implementationsavailable range of did [1024, so. 65535]. Both versions of TOTD use Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) increaseIntel CPU, by which 256. Anduses nowLSB webyte give order the (least explanation. significant A sbyte we sourceWe have port 53 summarized for all outgoing our results queries. in Table This 2. is trBIND,ivially first),disclosed whereas it in the [30], network the byte old order version is MSB of TOTD (most significant generated sourceWe haveport 53 summarized for all outgoing our results queries. in ThisTable is2. tr BIND,ivially Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) disclosedfirst), whereas it in the [30], network the byte old order version is MSB of TOTD (most significant generated PowerDNSpredictable. and As forUnbound mtd64ng, follow what the can guidelines be seen offrom RFC Table 5452 2, bytesequential first). numbersThe programmer as Transaction could haveIDs. beenThe increase used the of standard 256 is PowerDNSpredictable. andAs forUnbound mtd64ng, follow what the can guidelines be seen fromof RFC Table 5452 2, bytesequential first). numbersThe programmer as Transaction could haveIDs. beenThe increaseused the ofstandard 256 is [13]is that and the choose source a source port number port number range randomly is [32768, from 610 the00]. largest What the result of the facts that the notebook used for testing has an [13]is that and the choose source a sourceport number port number range randomlyis [32768, from 610 the00]. largest What the result of function the facts for that the the conversion, notebook butused omitting for testing it is has just an a availablecannot be range seen offrom [1024, the table65535]. is that Both the versions same sour of TOTDce ports use are Intel CPU, which uses LSB byte order (least significant byte availablecannot be rangeseen fromof [1024, the table 65535]. is that Both the versions same sour ofce TOTD ports useare featureIntel CPU, and notwhich a bug, uses as LSBTransaction byte order IDs (leastare just signifi identifierscant byte and sourceused for port querying 53 for the all AAAA outgoing record queries. and the This A record is tr iviallyfor the first), whereas the network byte order is MSB (most significant sourceused for port querying 53 for the allAAAA outgoing record queries. and the ThisA record is tr forivially the theyfirst), do whereas not convey the network any special byte meaning. order is MSB For more (most in significantformation predictable.same domain As for name. mtd64ng, This what is can deliberate be seen fromfrom Table the raw 2, byte first). The programmer could have been used the standard predictable.same domain As for name. mtd64ng, This what is deliberatecan be seen from from theTable raw 2, byteabout first). the bug, The whichprogrammer randomly could caused have anbeen unresponsiv used the standardeness of ismeasurement that the source results, port wenumber show rangeonly the is [32768,first 6 lines 610: 00]. What function for the conversion, but omitting it is just a ismeasurement that the source results, port we number show onlyrange the is first[32768, 6 lines 610: 00]. What the old version function of TOTD, for the and conversion, for its correction, but omitting please it isrefer just to a cannot48926 be seen from the table is that the same source ports are feature and not a bug, as Transaction IDs are just identifiers and cannot48926 be seen from the table is that the same source ports are feature[30], where and not we a bug, have as alsoTransaction described IDs the are eliminationjust identifiers of and its used48926 for querying the AAAA record and the A record for the they do not convey any special meaning. For more information used48926 for querying the AAAA record and the A record for the theyvulnerability do not convey for Transaction any special ID meaning. prediction For attack. more information same41556 domain name. This is deliberate from the raw about the bug, which randomly caused an unresponsiveness of same41556 domain name. This is deliberate from the raw aboutFig. the 7 shows bug, which the input randomly correlation caused and an autocorrelat unresponsivioneness of the of measurement41556 results, we show only the first 6 lines: the old version of TOTD, and for its correction, please refer to measurement41556 results, we show only the first 6 lines: theTransaction old version IDs of of TOTD, NEWTOTD. and for Theyits correction, seem to plbeease like refer noise, to 4892642713 [30], where we have also described the elimination of its 4892642713 [30],which whereis exactly we what have we also expected. described the elimination of its 4892642713 vulnerability for Transaction ID prediction attack. 4892642713 Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) vulnerabilityFig. 8 shows for the Transaction input correlation ID prediction and autocorrelat attack. ion of the 41556And it is also deliberate from the source code [38]. Although, Fig. 7 shows the input correlation and autocorrelation of the 41556And it is also deliberate from the source code [38]. Although, TransactionFig. 7 shows IDs the ofinput mtd64ng. correlation They and autocorrelat are two completelion of they this41556 phenomenon does not mean predictability in the bind Fig. 5. BIND, Transaction ID input correlation (left) and autocorrelationTransaction (right) IDs of NEWTOTD. They seem to be like noise, this41556 phenomenon does not mean predictability in the bind Transactionidentical graphs, IDs of asNEWTOTD. the two CSV They filesseem wereto be foundlike no aise,lso spoofing42713 attack model, we recommend the usage of different Fig. 8. mtd64ng, Transaction ID initial correlation (left) and autocorrelation (right) completelywhich is exactly identical. what Itwe is expected. visibly the graph of y=x function, spoofing42713 attack model, we recommend the usage of different Fig. 8. mtd64ng, Transaction ID initial correlation (left) and autocorrelation (right) whichcompletely is exactly identical. what Itwe is expected. visibly the graph of y=x function, source42713 ports for the AAAA and A record queries. Fig. 8. mtd64ng, Transaction ID initial correlatio n (left) and autocorrelation (right) becauseFig. 8 mtd64ngshows the reusesinput correlation the Transaction and autocorrelat ID of theion received of the source42713 ports for the AAAA and A record queries. Fig. 8. mtd64ng, Transaction ID initial correlation (left) and autocorrelation (right) because mtd64ng reuses the Transaction ID of the received AndIt can it is also also bedeliberate seen from from the the sourcesource code code, [38] that. Although, mtd64ng TransactionFig. 8 shows IDs the ofinput mtd64ng. correlation They and autocorrelat are two completelion of they ItAnd can it is also also be deliberate seen from from the the source source code,code [38] that. Although, mtd64ng reveal correlation between the consecutive Transaction IDs IDs. Before giving the explanation, let us have a look at the queryTransaction and sends IDs of both mtd64ng. of its own They queries are two with completel the samey thisentrusts phenomenon the source doesport selection not mean to predictabilitythe operating system. in the It bind can reveal correlation between the consecutive Transaction IDs IDs. Before giving the explanation, let us have a look at the Transactionidentical graphs, ID, which as theis a serious two CSV vulnerability. files were found also entruststhis phenomenon the source port does selection not mean to the predictability operating system. in the It bind can generatedreveal correlation by the DNS64 between program. the consecutive For simplicity, Transact we willion refer IDs autocorrelationIDs.9 Before giving of the the Transaction explanation, IDs let ofus OLDTOTDhave a look o atn thethe Transactionidentical graphs, ID, which as theis a serious two CSV vulnerability. files were found also spoofingbe satisfactory, attack ifmodel, the operating we recommend system complies the usage w ithof RFCdifferent 6056 generatedreveal correlation by the DNS64 between program. the consecutive For simplicity, Transact we willion refer IDs autocorrelationIDs. Before giving of the the Transaction explanation, IDs let ofus OLDTOTDhave a look o atn thethe completelyAs we already identical. mentioned, It is visibly mtd64ng the is graph a result of y=of xan function, ongoing bespoofing satisfactory, attack if model, the operating we recommend system complies the usage with of RFC different 6056 togenerated the first by one the asDNS64 program. Fig. 8.For mtd64ng,, andsimplicity, the Transaction second we will ID one initialrefer as correlatiorightautocorrelation> REPLACEn side(left) and of autocorrelation Fig. THIS of the 6. LINE Now, Transaction (right) WITH the predictability YOUR IDs of PAPER OLDTOTD is evIDENTIFICATIONen o moren the NUMBER (DOUBLECLICKcompletelyAs we already identical. mentioned, HERE It is TO visibly mtd64ng EDIT) the < is graph a result of y=of xan function, ongoing source[14], but ports we for contend the AAAA that is and safer A recordif source queries. port randomization togenerated the first by one the asDNS64 program. For, andsimplicity, the second we will one refer as rightautocorrelation side of Fig. of the 6. Now, Transaction the predictability IDs of OLDTOTD is even o moren the universitybecause mtd64ng project and reuses it not the yet Transaction ready to be IDused of in the production received [14],source but ports we forcontend the AAAA that is and safer A ifrecord source queries. port r andomization to the first one as , and the second one as right side of Fig. 6. Now, the predictability is even more becauseuniversity mtd64ng project and reuses it not the yet Transaction ready to be IDused of in the production received is Itdone can by also the beDNS seen or DNS64 from the implementation source code, itself. that mtd6 4ng . Fig. 8. mtd64ng, Transaction ID initial correlatiodeliberate.n (left) andLet autocorrelation us look into (right)the CSV file containing the (, ) is done by the DNS or DNS64 implementation itself. to the first one. as , and the second one as deliberate.right side Let of us Fig. look 6. into Now, the theCSV predictability file containin isg the ev en( more, ) Fig. 4.) Therefore,systemsquery we and had[31]. sends to make both ofa new its own series queries of with the same entrustsIt can the also source be seenport selection from the to sourcethe operating code, thatsystem. mtd6 It 4ngcan We used . scripts to extract the appropriate Transaction pairsdeliberate. for input LetTable correlationus 2.look Source into checking:Port the Randomness CSV file containinTest Resultsg the (, ) querysystems and [31]. sends both of its own queries with the same revealWe used correlation . scripts between to extract the consecutive the appropriate Transact Transactionion IDs pairsdeliberate.IDs. forBefore input Let giving correlationus look the into explanation, checking: the CSV file let containinus have ga thelook ( at, the) TransactionAs for PowerDNS ID, which and is Unbound,a serious vulnerability. we have also performed the entrusts the source port selection to the operating system. It can We used scripts to extract the appropriate Transaction pairs0, 55745 for input correlation checking: measurements usingTransaction Asa different for PowerDNS ID, command which and is line Unbound,a serious for vulnerability. we have as also performed the be satisfactory,VIII. MULTIPLE if the operating EQUIVALENT system Q UERIEScomplies V ULNERABILITYwith RFC 6056 IDsgeneratedWe from used the by textthe DNS64scriptsfile output toprogram. extract of the Forthe simplicity,appropriate program, we Transaction will and refer the pairsautocorrelation0, 55745 for input correlation of the Transaction checking: IDs of OLDTOTD on the As we already mentioned, mtd64ng is a result of an ongoing be satisfactory,VIII. MULTIPLE if the operating EQUIVALENT system QUERIES complies VULNERABILITY with RFC 6056 reveal correlation between the consecutive Transaction IDs IDs. BeforeDNS64 giving thesource explanation, ports observed let in usthe experimentshave a look at the follows: tests and evaluated the results. All their plots looked like the [14], but we contend that is saferESTING if source port randomization graphsIDs from were the prepared text file byoutput of the . program, and the 1,0, 5625755745 As we already mentioned, mtd64ng is a result of an ongoing TESTING graphsgeneratedtoIDs the from were first theby oneprepared thetext asDNS64 file byoutput program. of the For . , simplicity, and the program, second we will and one refer the as autocorrelationright1,0, 56257 55745Implementation side of Fig. of the 6. Now,Transaction the predictability IDs of OLDTOTD is even on more the plotsuniversity of BIND project or NEWTOTD,and it not yet thus ready we to can be stateused thatin production we found is[14], done but by we the contend DNS or thatDNS64 is safer implementation if source port itself. randomization graphs were prepared by . 2,1, 5676956257 minimum maximum std. dev. universityplots of BIND project or NEWTOTD,and it not yet thus ready we to can be stateused thatin production we found . deliberate.2,1, 5676956257 Let us look into the CSV file containing the (, ) systems [31]. is doneTo beby the able DNS to ortest, DNS64 whether implementation the examined itself. DNS64 tographs the firstwere oneprepared as by . , and the second one as right3,2, 57281 56769 side of Fig. 6. Now, the predictability is even more systemsno signs [31]. of Transaction ID predictability. (We omit the four To be able to test, whether the examined DNS64 pairs3,2, 57281 56769BINDfor input correlation1024 checking: 65535 18635 As for PowerDNS and Unbound, we have also performed the implementations send multiple equivalent queries concurrently, We used . scripts to extract the appropriate Transaction deliberate. Let us look into the CSV file containing the (, ) plots, because we see no point in including further four “random implementationsVIII. MULTIPLE send E multipleQUIVALENT equivalent QUERIES queries VULNERABILITY concurrently, Fig. 5 shows the input correlation and the autocorrelation of 4,3, 5779357281OLDTOTD 53 53 0 plots,testsAs andforbecause PowerDNSevaluated we see the andno results.point Unbound, in Allincluding wetheir have plots further also lo performed okedfour “randomlike thethe we had to modify the test program so that it can send multiple IDsFig.We from 5used shows the text the scripts file input output tocorrelation extract of the the and appropriate the autocorr program, Transactionelation and theof pairs4,0,3, 57793 5574557281for input correlation checking: art” images.) we hadVIII. to modifyMULTIPLE the EtestQUIVALENT TprogramESTING QsoUERIES that it VcanULNERABILITY send multiple theFig. Transaction 5 shows IDsthe inputof BIND. correlation They seem and theto beautocorr like noise,elation thus of Whereas4, 57793 the Transaction IDs start from 0 and increase by testsart” images.) and evaluated the results. All their plots looked like the thegraphsFig. Transaction 5were shows prepared IDsthe inputof by BIND. correlation They .seem and theto beautocorr like noise,elation thus of Whereas0,1,4, 557455625757793NEWTOTD the Transaction 53 IDs53 start from 0 0and increase by The capture filterplots ensured of BIND that oronly NEWTOTD, IPv4 packets thus s entwe canfrom state that we found queries for the same domainT ESTINGname. wetheIDs can Transactionfrom say the that text no IDs predictabilityfile of output BIND. of They problemsthe seem wereto be program, revlikeealed noise, and by thus ourthe Whereas the Transaction IDs start from 0 and increase by To be able to test, whether the examined DNS64 we can say that no predictability problems were revealed by our 1, the Transaction IDs start from a different number and plotsno signs of BIND of Transaction or NEWTOTD, ID predictability. thus we can (Westate omitthat wethe found four wethe can Transaction say that no IDs predictability of BIND. They problems seem wereto be revlikeealed noise, by thusour 1, the1,2,Whereas 5625756769mtd64ng Transaction the Transaction 32768 IDs start IDs from 61000 start a fromdifferent 0 8136and number increase and by the DNS64 server programVII. at SOURCE (withPORT NsourceUMBER IP R addressANDOMNESS TESTING To be able to test, whether the examined DNS64 simplewegraphs can evaluationweresay that prepared no method. predictability by problems. were revealed by our increase1, the by Transaction 512. The CSV IDs file start containing from a differentthe (, number) pairs andfor no signsVII. of S TransactionOURCE PORT ID N UMBER predictability. RANDOMNESS (We omit TESTING the four implementations send multiple equivalent queries concurrently, simple evaluation method. increase by 512. The CSV file containing the (, ) pairs for plots, because we see no point in including further four “random we can say that no predictability problems were revealed by our 1, 2,3, the 5676957281PowerDNS Transaction 1025 IDs start from 65534 a different 18655 number and 10.0.0.2) to the authoritative DNS server program (listening at implementations send multiple equivalent queries concurrently, simpleThe leftevaluation graph ofmethod. Fig. 6 shows the input correlation of the autocorrelationincrease by 512. checking The CSV can file give containing us further the help: (, ) pairs for plots,art”The images.) because results ofwe the see Transaction no point in includingID prediction further tests four could “random have we had to modify the test program so that it can send multiple simpleTheFig. left5evaluation shows graph the ofmethod. input Fig. 6correlation shows the and input the correlatioautocorrelationn of the of autocorrelationincrease3,4, 5728157793Unbound by 512. checking The 1024CSV can file give containing 65535us further the help: ( 17467, ) pairs for TransactionThe left graphIDs of of OLDTOTD. Fig. 6 shows The the regular input correlatiopatterns inn dicateof the autocorrelation55745, 56001 checking can give us further help: port 53 of ) beart”been included. images.) used alsoThe outputfor port file number contained randomness only the tests, but queriesweThe had forto modifythe same the domain [35]test programtest name. program so that was it usedcan se asnd a multiplestarting TransactiontheThe Transaction left graphIDs IDsof of OLDTOTD. ofFig. BIND. 6 shows They The the seem regular input to be correlatiopatterns like noise, inn dicateof thus the autocorrelation55745,Whereas 56001 the checking Transaction can give IDs us start further from help: 0 and increase by been used also for port number randomness tests, but The [35] test program was used as a starting Fig. 8. mtd64ng, Transaction ID initial correlatiothatTransactionFig. theren (left) 5 showsis and a IDs problemautocorrelation the of inputOLDTOTD. with correlation (right) the predictability The and regular the ofautocorr patterns the Transactionelation indicate of 56257, 55745,4, 57793 5651356001 source port numbers.did not As include expected, the theport resultnumbers files in containedits output. (Its default output queries for the same domain name. thatTransactionwe canthere say is thata IDs problem no of predictability OLDTOTD. with the predictability problems The regular were of patterns therev Transactionealed in bydicate our 56257,55745, 5651356001 did notVII. include SOURCE the port PORT numbers NUMBER in its R ANDOMNESSoutput. (Its default TESTING output point of our new program. Its arguments the Transaction IDs of BIND. They seem to be like noise, thus 1, Whereas the Transaction the Transaction IDs start IDs from start a fromdifferent 0 and number increase and by 131072 numbers, except for BIND, in the case of which there point of our new program. Its arguments that there is a problem with the predictability of the Transaction 56257, 56513 containsVII. the S OURCE same dataPORT asN UMBER the Wireshark RANDOMNESS screen T ESTING shown in are: , , , and . Parameter can thatsimple there evaluation is a problem method. with the predictability of the Transaction increase56769,56257, by 5702556513 512. The CSV file containing the (, ) pairs for containsThe results the sameof the dataTransaction as the ID Wireshark prediction screen tests could show haven in are: , , , and . Parameter can we can say that no predictability problems were revealed by our 1, the Transaction IDs startFig. from 6. OLDTOTD, a different Transaction number ID input and correlationwere 131073 (left) and numbers autocorrelation in the (right) file. We have investigated the case reveal correlation between the consecutive Transaction IDs IDs.The Before left graph giving of theFig. explanation, 6 shows the let input us have correlatio a lookn of at the autocorrelation57281, 57537 checking can give us further help: The results of the Transaction ID prediction tests could have simple evaluation method. increase by 512. The CSV file containing the (, ) pairs for and found that it wasbeen so usedbecause also BIND for port also number sent a qrandomnessuery for the tests, but The [35] test program was used as a starting generated by the DNS64 program. For simplicity, we will refer autocorrelation of the Transaction IDs of OLDTOTD on the 57793, 58049 been used also for port number randomness tests, but TransactionThe left graph IDs of of OLDTOTD. Fig. 6 shows The the regularinput correlatio patterns nin ofdicate the autocorrelation55745, 56001 checking can give us further help: IP addresses of thedid rootnot include DNS the servers. port numbers None of in its the output. other (Its default output pointThe of our new [35] test program program. was used Its as arguments a starting to the first one as , and the second one as thatright there side is ofa problem Fig. 6. with Now, the the predictability predictability of the is Transaction even more Itwhere is well the visible string that thewas consecutive replaced by Transaction the name of IDs the always tested method is more thoroughdid not includethan that. the port numbers in its output. (Its default output Transaction IDs of OLDTOTD. The regular patterns indicate 55745,56257, 5600156513 implementations didcontains so. the same data as the Wireshark screen shown in are:point ,of , our new , and program.. Parameter Its arguments can . deliberate. Let us look into the CSV file containing the (, ) increaseDNS64 implementation. by 256. And now we give the explanation. As we We have checkedcontains two the kinds same data of correlations as the Wireshark using screen shown in that there is a problem with the predictability of the Transaction 56257, 56513 We have summarized our results in Table 2. BIND, are: , , , and . Parameter can We used scripts to extract the appropriate Transaction pairs for input correlation checking: disclosed it in [30], the old version of TOTD generated visualization. Before introducing them, let us define some PowerDNS and Unbound follow the guidelines of RFC 5452 0, 55745 sequential numbers as Transaction IDs. The increase of 256 is IDs from the text file output of the program, and the [13]notations and choose first. Let a source denote port the number ordinal randomly number fromof a message the largest in 1, 56257 thePredictability result of the factsof the that Transaction the notebook IDs isused a hard for testingquestion. has E.g. an the message sequence introduced in section IV.E, where is in graphs were prepared by . available range of [1024, 65535]. Both versions of TOTD use 2, 56769 Intelif pseudorandom CPU, which numbersuses LSB are byte used order that (least were signifigeneratecantd bybyte a source[1, 6]. Let port denote 53 for the all ordinal outgoing number queries. of the This AAAA is tr iviallyrecord 3, 57281 first),linear whereascongruential the network generator byte (LCG), order thenis MSB they (most are predictable. significant predictable.request sent As by for the mtd64ng, what program,can be seen where from isTable in [0,2, Fig. 5 shows the input correlation and the autocorrelation of 204, 57793 byteThere first). are The a high programmer number ofcould JUNE methods have 2018 been described• VOLUME used thX fore• NUMBERstandard testing 2 is65535]. that the Let source denote port numberthe Transaction range is ID[32768, of the 610 th00]. message What the Transaction IDs of BIND. They seem to be like noise, thus Whereas the Transaction IDs start from 0 and increase by randomness both in university lecture notes [36] and research function for the conversion, but omitting it is just a cannotfrom the be sixseen messages from the usedtable tois that resolve the same the thsour queryce ports of are the we can say that no predictability problems were revealed by our 1, the Transaction IDs start from a different number and featurepapers [37].and not a bug, as Transaction IDs are just identifiers and used for querying program. the AAAA As the record test programand the A uses record sequential for the simple evaluation method. increase by 512. The CSV file containing the (, ) pairs for Since our solution of using a testbed ensures us full control they do not convey any special meaning. For more information sameTransaction domain IDs name.from 0, it Thisis sure is that: deliberate = = from . the raw The left graph of Fig. 6 shows the input correlation of the autocorrelation checking can give us further help: of the testing method, and gives us access to the raw results, we about the bug, which randomly caused an unresponsiveness of measurementWe use two results, graphs. we An show (x, y) only plot the of firstthe (6 lines, :) pairs may Transaction IDs of OLDTOTD. The regular patterns indicate 55745, 56001 thehave old the version possibility of TOTD, to use and multiple for its methodscorrection, for pl eveasealuation refer toif reveal correlation between the Transaction ID used by the needed. We decided to use first a simple, graphical method, 48926 that there is a problem with the predictability of the Transaction 56257, 56513 [30], where we have also described the elimination of its program and the first Transaction ID generated which is somewhat similar to that of the earlier mentioned 48926 vulnerability for Transaction ID prediction attack. by the DNS64 program. An (x, y) plot of the (, ) pairs may entropy tester of DNSOARC [19], but we contend that our 41556 Fig. 7 shows the input correlation and autocorrelation of the 41556 Transaction IDs of NEWTOTD. They seem to be like noise, 42713 which is exactly what we expected. 42713 Fig. 8 shows the input correlation and autocorrelation of the And it is also deliberate from the source code [38]. Although, Transaction IDs of mtd64ng. They are two completely this phenomenon does not mean predictability in the bind identical graphs, as the two CSV files were found also spoofing attack model, we recommend the usage of different completely identical. It is visibly the graph of y=x function, source ports for the AAAA and A record queries. because mtd64ng reuses the Transaction ID of the received It can also be seen from the source code, that mtd64ng query and sends both of its own queries with the same entrusts the source port selection to the operating system. It can Transaction ID, which is a serious vulnerability. be satisfactory, if the operating system complies with RFC 6056 As we already mentioned, mtd64ng is a result of an ongoing [14], but we contend that is safer if source port randomization university project and it not yet ready to be used in production is done by the DNS or DNS64 implementation itself. systems [31]. As for PowerDNS and Unbound, we have also performed the VIII. MULTIPLE EQUIVALENT QUERIES VULNERABILITY tests and evaluated the results. All their plots looked like the TESTING plots of BIND or NEWTOTD, thus we can state that we found no signs of Transaction ID predictability. (We omit the four To be able to test, whether the examined DNS64 plots, because we see no point in including further four “random implementations send multiple equivalent queries concurrently, art” images.) we had to modify the test program so that it can send multiple queries for the same domain name. VII. SOURCE PORT NUMBER RANDOMNESS TESTING The results of the Transaction ID prediction tests could have been used also for port number randomness tests, but The [35] test program was used as a starting did not include the port numbers in its output. (Its default output point of our new program. Its arguments contains the same data as the Wireshark screen shown in are: , , , and . Parameter can 9 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 9 Fig. 4.) Therefore, we had to make a new series of > REPLACETable THIS 2. Source LINE Port WITH Randomness YOUR Test PAPER Results IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < measurements using a different command line for as 8 INFOCOMMUNICATIONSsource JOURNAL ports observed in the experiments Fig. 4.) Therefore, we had to make a new series of DNS64 Table 2. Source Port Randomness Test Results follows:Fig. 4.) Therefore, we had to make a new series of > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < ImplementationTable 2. Source Port Randomness Test Results Methodology for DNS Cache Poisoning Vulnerability 8 9 minimum maximum std. dev. measurements using a different command line for as Analysis of DNS64 Implementations > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACEBINDDNS64 THIS1024source LINE ports WITH observed 65535 YOUR in the PAPER experiments 18635 IDENTIFICATION follows: NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACEDNS64 THIS LINE WITH YOUR PAPER IDENTIFICATIONfollows: NUMBER (DOUBLECLICK HERE TO EDIT) < Implementation minimum maximum std. dev. OLDTOTD 53minimum 53 maximum 0 std. dev. Fig. 4.) Therefore, we had to make a new series of NEWTOTDBIND Table 2. Source 531024 Port Randomness53 65535 Test Results0 18635 Fig. 4.) Therefore, we had to make a new series of Table 2. Source Port Randomness Test Results measurementsThe capture usingfilter ensureda different that command only IPv4 line packets for sent from as mtd64ngOLDTOTD 32768 53 6100053 81360 measurements using a different command line for as source ports observed in the experiments the DNS64 server program at (with source IP address DNS64 source ports observed in the experiments follows:follows: PowerDNSNEWTOTD 1025 53 6553453 186550 10.0.0.2)The capture to the filterauthoritative ensured DNS that onlyserver IPv4 program packets (listening sent from at ImplementationImplementation minimum maximum std. dev. The capture filter ensured that only IPv4 packets sent from mtd64ng 32768minimum 61000maximum 8136std. dev. Unboundmtd64ng 1024 32768 65535 61000 17467 8136 portthe DNS6453 of server) be included.program atThe output (with file contained source IP only address the BIND 1024 65535 18635 18635 PowerDNS 1025 65534 18655 source10.0.0.2) port to numbers.the authoritative As expected, DNS server the result program files ( listeningcontained at OLDTOTD 53 53 0 10.0.0.2) to the authoritative DNS server program (listening at UnboundOLDTOTD 102453 6553553 174670 131072port 53 numbers,of ) be except included. for BIND,The output in the file case contained of whi chonly there the 56769,Unbound 57025 1024 65535 17467 port 53 of ) be included. The output file contained only the NEWTOTD 53 53 00 weresourceThe 131073 capture port numbers.numbers filter ensured in As the expected, file. that We only have the IPv4 resultinvestigat packets files ed scontainedent the from case 57281, 57537 sourceThe capture port numbers. filter ensured As expected, that only the IPv4 result packets files containedsent from mtd64ng 32768 61000 8136 andthe131072 DNS64found numbers, that server it was exceptprogram so because for at BIND, BIND in (with alsothe casesent source aof q uerywhiIP addressch for there the 57793,56769, 5804957025 the131072 DNS64 numbers, server exceptprogram for at BIND, in (withthe case source of whi IP chaddress there 56769,PowerDNS 57025 1025 65534 18655 IP10.0.0.2)were addresses 131073 to the numbers of authoritative the rootin the DNS DNSfile. We servers.server have program investigat None of(listening ed the the o thercase at It57281, isPowerDNS well 57537 visible that 1025 the consecutive 65534 Transaction 18655 IDs always 10.0.0.2)were 131073 to the numbers authoritative in the file. DNS We server have program investigat (listeninged the case at 57281,Unbound 57537 1024 65535 17467 implementationsportand 53found of that) it be didwas included. so. so because The BINDoutput alsofile containedsent a query only for the the increase57793,Unbound by 58049 256. And 1024 now we give 65535 the explanation. 17467 As we portand found53 of that it) bewas included. so because The BIND output also file sent contained a query only for the 57793, 58049 sourceIPWe addresses porthave numbers. summarized of the Asroot expected, DNSour results servers. the result in None Table files of 2. contained the BIND, other disclosedIt is well it visible in [30], that thethe consecutive old version Transaction of TOTD IDs gener alwaysated sourceIP addresses port numbers. of the root As expected, DNS servers. the result None files of contained the other It is well visible that the consecutive Transaction IDs always PowerDNS131072implementations numbers, and Unbound didexcept so. for follow BIND, the in guidelines the case of of whi RFCch there5452 sequentialincrease56769, by 57025numbers 256. And as Transaction now we give IDs. the The explanation. increase of A256s weis 131072implementations numbers, did except so. for BIND, in the case of which there increase56769, by57025 256. And now we give the explanation. As we [13]wereWe and 131073 havechoose numbers summarized a source in portthe file. ournumber We results haverandomly investigat in Table fromed the2. the largest BIND, case thedisclosed 57281,result of57537 it the in facts [30], that the the old notebook version used of for TOTD testing gener hasated an wereWe 131073 have numbers summarized in the ourfile. We results have ininvestigat Table ed2. the BIND, case disclosed57281, 57537 it in [30], the old version of TOTD generated availableandPowerDNS found range that and it of wasUnbound [1024, so because 65535]. follow BIND Boththe guidelinesalso versions sent a ofqofuery TOTDRFC for 5 theuse452 Intelsequential57793, CPU, 58049 numberswhich uses as TransactionLSB byte order IDs. (leastThe increase significant of 256 byte is andPowerDNS found that and it Unboundwas so because follow BIND the guidelines also sent a of query RFC for 5452 the sequential57793, 58049 numbers as Transaction IDs. The increase of 256 is sourceIP[13] addresses and port choose 53 of a for thesource all root port outgoing DNS number servers. queries. randomly None This from of is thethe tr iviallylargest other first),theIt result is whereas well of visible the the facts network that that the thebyteconsecutive notebook order is Transaction MSBused for(most testing IDssignificant always has an IP[13] addresses and choose of a source the root port DNS number servers. randomly None from of the the largest other theIt result is well of visible the facts that that the theconsecutive notebook Transaction used for testing IDs alwayshas an predictable.implementationsavailable range As for ofdid [1024,mtd64ng, so. 65535]. what Both can beversions seen fromof TOTD Table use 2, byteIntelincrease first). CPU, by The which 256. programmer Anduses nowLSB could webyte give haveorder the been (least explanation. used signifi the cantstandard As byte we implementationsavailable range of did [1024, so. 65535]. Both versions of TOTD use Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) Intelincrease CPU, by which 256. Anduses nowLSB webyte give order the (least explanation. significant A sbyte we issource thatWe the have port source 53 summarized forport allnumber outgoing our range results queries.is [32768, in Table This 610 2. is00]. trBIND, iviallyWhat first),disclosed whereas function it in the [30], network for the conversion,byte old order version is but MSB of omitting TOTD (most significantit gener is juatedst a sourceWe haveport 53 summarized for all outgoing our results queries. in ThisTable is2. tr BIND,ivially Fig. 7. NEWTOTD, Transaction ID input correlation (left) and autocorrelation (right) first),disclosed whereas it in the [30], network the byte old order version is MSB of TOTD (most significant generated cannotPowerDNSpredictable. be seen and As from forUnbound mtd64ng, the table follow is what that the can theguidelines samebe seen sour offrom ceRFC ports Table 5452 are 2, bytesequential first). numbersThe programmer as Transaction could haveIDs. beenThe increase used the of standard 256 is PowerDNSpredictable.10 andAs forUnbound mtd64ng, follow what the can guidelines be seen fromof RFC Table 5452 2, featurebytesequential first). and numbersnotThe a programmer bug, as as Transaction Transaction could haveIDs. IDs beenareThe just increaseused identifiers the ofstandard 256 and is used[13]is that andfor the choosequerying source a source theport AAAA number port number record range randomly andis [32768, the A from record610 the00]. largestfor What the the result of the facts that the notebook used for testing has an [13]is >that REPLACE and the choose source THISa sourceport LINE number port WITH number range YOUR randomlyis [32768, PAPER from 610 IDENTIFICATION the00]. largest What NUMBER (DOUBLECLICK HERE TO EDIT) < theythe resultdo not of functionconvey the facts any for that specialthe the conversion, notebook meaning. but usedFor omitting more for testing in formationit is has just an a sameavailablecannot domain be range seen offrom name. [1024, the table65535]. This is is that Both deliberate the versions same sour from of TOTDce theports use raw are Intel CPU, which uses LSB byte order (least significant byte availablecannot be rangeseen fromof [1024, the table 65535]. is that Both the versions same sour ofce TOTD ports useare aboutfeatureIntel CPU,the and bug, notwhich which a bug, uses randomly as LSBTransaction byte caused order IDs an (leastare unresponsiv just signifi identifierscanteness byte and of measurementsourceused for port querying 53results, for the we all AAAA show outgoing onlyrecord the queries. and first the 6 This linesA record : is tr iviallyfor the first), whereas the network byte order is MSB (most significant sourceused for port querying 53 for the allAAAA outgoing record queries. and the ThisA record is tr forivially the thetheyfirst), old do whereas version not convey theof TOTD, network any special and byte for meaning. order its correction, is MSB For more (most please in significantformation refer to predictable.same48926 domain As for name. mtd64ng, This what is can deliberate be seen fromfrom Table the raw 2, byte first). The programmer could have been used the standard predictable.same domain As for name. mtd64ng, This what is deliberatecan be seen from from theTable raw 2, [30],byteabout first). wherethe bug, The we whichprogrammer have randomly also describedcould caused have theanbeen unresponsiv elimination used the standardeness of itsof ismeasurement 48926that the source results, port wenumber show rangeonly the is [32768,first 6 lines 610: 00]. What function for the conversion, but omitting it is just a ismeasurement that the source results, port we number show onlyrange the is first[32768, 6 lines 610: 00]. What vulnerabilitythe old version function for of Transaction TOTD, for the and conversion, ID for prediction its correction, but attack. omitting pl ease it isrefer just to a cannot4155648926 be seen from the table is that the same source ports are featureFig. 7 and shows not thea bug, input as Transactioncorrelation andIDs autocorrelatare just identifiersion of andthe cannot48926 be seen from the table is that the same source ports are [30],feature where and not we a bug, have as alsoTransaction described IDs the are eliminationjust identifiers of and its used4155648926 for querying the AAAA record and the A record for the Transactionthey do not conveyIDs of NEWTOTD.any special meaning. They seem For moreto be in likeformation noise, used48926 for querying the AAAA record and the A record for the vulnerabilitythey do not convey for Transaction any special ID meaning. prediction For attack. more information same4271341556 domain name. This is deliberate from the raw whichabout isthe exactly bug, which what werandomly expected. caused an unresponsiveness of same41556 domain name. This is deliberate from the raw aboutFig. the 7 shows bug, which the input randomly correlation caused and an autocorrelat unresponsivioneness of the of measurement4271341556 results, we show only the first 6 lines: theFig. old 8 versionshows theof TOTD,input correlation and for its and correction, autocorrelat pleaseion refer of the to measurement41556 results, we showFig. only 9. Wireshark the first capture6 lines taken: during the birthday attack vulnerability test of BIND. Transactionthe old version IDs of of TOTD, NEWTOTD. and for Theyits correction, seem to plbeease like refer noise, to And4892642713 it is also deliberate from the source code [38]. Although, Transaction[30], where IDs we have of mtd64ng. also described They the are elimination two completel of itsy 4892642713 which[30], whereis exactly we what have we also expected. described the elimination of its this4892642713 phenomenon does not mean predictability in the bind identicalvulnerability graphs, for Transaction as the two ID CSVprediction files attack. were found also 4892642713 vulnerabilityFig. 8 shows for the Transaction input correlation ID prediction and autocorrelat attack. ion of the spoofing41556And it attackis also model,deliberate we from recommend the source the code usage [38] of. Although,different completelyFig. 7 shows identical. the input It is correlation visibly the and graph autocorrelat of y=x ion function, of the 41556And it is also deliberate from the source code [38]. Although, TransactionFig. 7 shows IDs the ofinput mtd64ng. correlation They and autocorrelat are two completelion of they sourcethis41556 phenomenon ports for the doesAAAA not and mean A record predictability queries. in the bind becauseTransaction mtd64ng IDs of reuses NEWTOTD. the Transaction They seem ID to of be the like received noise, this41556 phenomenon does not mean predictability in the bind identicalTransaction graphs, IDs of asNEWTOTD. the two CSV They filesseem wereto be foundlike no aise,lso spoofingIt42713 can alsoattack be model, seen fromwe recommend the source the code, usage that of mtd6 different4ng querywhich andis exactly sends what both we of expected. its own queries with the same spoofing42713 attack model, we recommend the usage of different completelywhich is exactly identical. what Itwe is expected. visibly the graph of y=x function, entrustssource42713 ports the source for the port AAAA selection and Ato recordthe operating queries. system. It can TransactionFig. 8 shows ID, whichthe input is a correlation serious vulnerability. and autocorrelat ion of the source42713 ports for the AAAA and A record queries. becauseFig. 8 mtd64ngshows the reusesinput correlation the Transaction and autocorrelat ID of theion received of the be Andsatisfactory,It can it is also also if bedeliberate the seen operating from from thesystem the sourcesource complies code code, [38] w thatith. Although, RFC mtd6 60564ng TransactionAs we already IDs mentioned, of mtd64ng. mtd64ng They is a are result two of an completel ongoingy AndIt can it is also also be deliberate seen from from the the source source code,code [38] that. Although, mtd64ng queryTransaction and sends IDs of both mtd64ng. of its own They queries are two with completel the samey [14],thisentrusts phenomenonbut thewe sourcecontend doesport that selection not is safer mean toif predictabilitythesource operating port r andomizationsystem. in the It bind can universityTransactionidentical project graphs, ID, which and as it theis not a serious twoyet ready CSV vulnerability. to files be used were in foundproduction also thisentrusts phenomenon the source port does selection not mean to the predictability operating system. in the It bind can Transactionidentical graphs, ID, which as theis a serious two CSV vulnerability. files were found also isspoofingbe done satisfactory, by attack the DNS ifmodel, the or operating DNS64 we recommend implementationsystem complies the usage itself. w ithof RFCdifferent 6056 systemscompletelyAs we [31]. already identical. mentioned, It is visibly mtd64ng the is graph a result of y=of xan function, ongoing bespoofing satisfactory, attack if model, the operating we recommend system complies the usage with of RFC different 6056 Fig. 8. mtd64ng, Transaction ID initial correlation (left) and autocorrelation (right) completelyAs we already identical. mentioned, It is visibly mtd64ng the is graph a result of y=of xan function, ongoing source[14], but ports we for contend the AAAA that is and safer A recordif source queries. port randomization becauseAs for PowerDNS mtd64ng reuses and Unbound, the Transaction we have IDalso of performed the received the [14],source but ports we forcontend the AAAA that isFig. and safer 10. A Wireshark ifrecord source queries. capture port rtaken andomization during the birthda y attack vulnerability test of OLDTOTD. universitybecause mtd64ng project and reuses it not the yet Transaction ready to be IDused of in the production received is Itdone VIII. can by also MtheULTIPLE beDNS seen or E QUIVALENTDNS64 from the implementation source QUERIES code, VULNERABILITY itself. that mtd6 4ng Fig. 8. mtd64ng, Transaction ID initial correlation (left) and autocorrelation (right) testssystemsquery and and [31].evaluated sends boththe results. of its All own their queries plots lo withoked the like sa theme is doneIt can by also the DNS be seen or DNS64 from the implementation source code, itself. that mtd64ng systemsquery and [31]. sends both of its own queries with the same entrusts the source port selectionTESTING to the operating system. It can reveal correlation between the consecutive Transaction IDs IDs. Before giving the explanation, let us have a look at the plotsTransactionAs of for BIND PowerDNS ID, or which NEWTOTD, and is Unbound,a serious thus vulnerability. we havecan state also thatperformed we found the entrusts the source port selection to the operating system. It can TransactionAs for PowerDNS ID, which and is Unbound,a serious vulnerability. we have also performed the be satisfactory,VIII. MULTIPLE if the operating EQUIVALENT system Q UERIEScomplies V ULNERABILITYwith RFC 6056 generated by the DNS64 program. For simplicity, we will refer autocorrelation of the Transaction IDs of OLDTOTD on the notests As signs and we ofalreadyevaluated Transaction mentioned, the results.ID predictability.mtd64ng All their is aplots result (We lo omitofoked an the ongoinglike four the beTo satisfactory,VIII. be M ableULTIPLE if the to operating test,EQUIVALENT whether system Q UERIES thecomplies examined VULNERABILITY with RFC DNS64 6056 reveal correlation between the consecutive Transaction IDs IDs. Before giving the explanation, let us have a look at the testsAs andwe alreadyevaluated mentioned, the results. mtd64ng All their is aplots result lo ofoked an ongoinglike the [14], but we contend that isT saferESTING if source port randomization to the first one as , and the second one as right side of Fig. 6. Now, the predictability is even more plots,university because project we see and no it point not yet in includingready to be further used fourin production “random implementations[14], but we contend send multiplethat isT saferESTING equivalent if source queries port r coandomizationncurrently, generated by the DNS64 program. For simplicity, we will refer autocorrelation of the Transaction IDs of OLDTOTD on the plotsuniversity of BIND project or NEWTOTD,and it not yet thus ready we to can be stateused thatin production we found is done by the DNS or DNS64 implementation itself. . deliberate. Let us look into the CSV file containing the (, ) art”systems images.) [31]. weis done Tohad tobeby modify the able DNS the to or testtest, DNS64 program whether implementation so that the it examinedcan itself. send multiple DNS64 to the first one as , and the second one as right side of Fig. 6. Now, the predictability is even more nosystems signs [31]. of Transaction ID predictability. (We omit the four To be able to test, whether the examined DNS64 We used scripts to extract the appropriate Transaction pairs for input correlation checking: As for PowerDNS and Unbound, we have also performed the queriesimplementations for the same send domain multiple name. equivalent queries concurrently, . deliberate. Let us look into the CSV file containing the (, ) plots,As forbecause PowerDNS we see andno point Unbound, in including we have further also performed four “random the implementationsVIII. MULTIPLE send E multipleQUIVALENT equivalent QUERIES queries VULNERABILITY concurrently, 0, 55745 tests andVII. evaluatedSOURCE PtheORT results. NUMBER All RtheirANDOMNESS plots looked TESTING like the we hadVIII. to modifyMULTIPLE the EtestQUIVALENT program QsoUERIES that it VcanULNERABILITY send multiple IDsWe from used the text scripts file output to extract of the the appropriate program, Transaction and the pairs for input correlation checking: testsart” images.) and evaluated the results. All their plots looked like the we had to modify the test TprogramESTING so that it can send multiple plots of BIND or NEWTOTD, thus we can state that we found queries for the same domainT ESTINGname. graphsIDs from were the prepared text file byoutput of the . program, and the 0,1, 5574556257 queries for the same domain name. plotsnoThe signs of results BIND of Transactionof or the NEWTOTD, Transaction ID predictability. thus ID predictionwe can (Westate tests omitthat could wethe found havefour To be able to test, whether the examined DNS64 graphs were prepared by . 1,2, 5625756769 VII. SOURCE PORT NUMBER RANDOMNESS TESTING To be able to test, whether the examined DNS64 beennoplots, signs used becauseVII. ofalso S TransactionOURCE wefor seeport P noORT number point ID N UMBER predictability. in randomness including RANDOMNESS further tests, (We omitfourbu TtESTING “randomthe four implementationsThe send [35] multiple test equivalentprogram was queries used co asncurrently, a starting 2,3, 5676957281 implementations send multipleFig. 11. equivalent Wireshark queriescapture taken concurrently, during the birthda y attack vulnerability test of NEWTOTD. 9 didplots,art”The not images.) because includeresults of wethe the see port Transaction no numbers point in in includingID its prediction output. further (It testss default four could “random output have pointwe had of to our modify new the test program so that program. it can se Itsnd arguments multiple Fig. 5 shows the input correlation and the autocorrelation of 3,4, 5728157793 9 we had to modify the test program so that it can send multiple 9 containsart”been images.) used the also same for port data number as the randomness Wireshark tests, screen bu showt n in are:queriesThe , for, the same ,domain [35] test name. program and was .used Parameter as a starting can the Transaction IDs of BIND. They seem to be like noise, thus Whereas the Transaction> REPLACE IDs start THIS from LINE 0 and WITH increase YOUR by PAPER IDENTIFICATIONbeen used NUMBER also for port(DOUBLECLICK number randomness HERE tests, TO buEDIT)t < The [35] test program was used as a starting Fig. 5 shows the input correlation and the autocorrelation of 4, 57793 > >REPLACE REPLACE THIS THIS LINE LINE WITH WITH YOUR YOUR PAPER PAPER IDENTIFICATION IDENTIFICATIONdid not NUMBER includeNUMBER the (DOUBLECLICK port(DOUBLECLICK numbers in its HERE output. HERE TO (It TOs EDIT) default EDIT) < output < queries for the same domain name. we can say that no predictability problems were revealed by our did notVII. include SOURCE the port PORT numbers NUMBER in its R ANDOMNESSoutput. (Its default TESTING output bepoint used of to our perform new multiple tests with a program.different domain Its arguments name VMnet1 interface using the capture filter. the Transaction IDs of BIND. They seem to be like noise, thus 1, Whereas the Transaction the Transaction IDs start IDs from start a fromdifferent 0 and number increase and by point of our new program. Its arguments containsVII. the S OURCE same dataPORT asN UMBER the Wireshark RANDOMNESS screen T ESTING shown in inare: each , test., It is for convenience:, when and multiple . Parameter tests are done, can The usual command line was: simple evaluation method. increase by 512. The CSV file containing the (, ) pairs for containsFig.The 4.) results the Therefore, sameof the dataTransaction we as had the ID Wireshark to prediction make screena tests new could show series haven in of are: , , , and . Parameter can we can say that no predictability problems were revealed by our 1, the Transaction IDs start Table from 2. a Source different Port Randomnessnumber and Test Results Fig. 4.) Therefore, we had to make a new series of The left graph of Fig. 6 shows the input correlation of the autocorrelation checking can giveTable us 2. further Source Porthelp: Randomness Test Results measurementsThe results of theusing Transaction a different ID command prediction line tests for could have as the DNS64 server may cache the previously used domain names simple evaluation method. increase by 512. The CSV file containing the (, ) pairs for measurementsbeenmeasurements used also usingfor using port a differentanumber different randomnesscommand command line tests,line for forbu t as as The [35] test program was used as a starting source ports observed in the experiments follows: and it is easier to use a different one for a new test, than TransactionThe left graph IDs of of OLDTOTD. Fig. 6 shows The the regularinput correlatio patterns nin ofdicate the autocorrelation55745, 56001 checking canDNS64 give us furthersource help: ports observed in the experiments beendidfollows: not used include also forthe port numbersnumber randomness in its output. tests, (Its default but output The [35] test program was used as a starting DNS64 source ports observed in the experiments follows: point of our new program. Its arguments that there is a problem with the predictability of the Transaction 56257, 56513 Implementation minimum maximum std. dev. did not include the port numbers in its output. (Its default output restarting the DNS64 server. Parameter specifies the number (However, sometimes different values were used for , e.g. Transaction IDs of OLDTOTD. The regular patterns indicate 55745, 56001 Implementation minimum maximum std. dev. contains the same data as the Wireshark screen shown in are:point ,of , our new , and program.. Parameter Its arguments can minimum maximum std. dev. contains the same data as the Wireshark screen shown in of queries to be sent. The rest of the parameters are to be 3 instead of 0 in the case shown in Fig. 9.) that there is a problem with the predictability of the Transaction 56257, 56513 BIND 1024 65535 18635 are: , , , and . Parameter can BIND 1024 65535 18635 interpreted as that of the original test program, that is, The results produced by BIND can be seen in Fig. 9. OLDTOTD 53 53 0 OLDTOTD 53 53 0 , and specify the timeout value of Although we sent two queries for the AAAA record of the same NEWTOTD 53 53 0 NEWTOTD 53 53 0 The capture filter ensured that only IPv4 packets sent from the receive function, the IPv6 address (or host name) of the domain name, BIND sent only one request to the authoritative NEWTOTD 53 53 0 TheThe capture capture filter filter ensured ensured that that only only IPv4 IPv4 packets packets sent sent from from mtd64ng 32768 61000 8136 the DNS64 server program at (with source IP address DNS64 server to be tested and the port number, where the DNS server for the AAAA record of the given domain name. mtd64ng 32768 61000 8136 thethe DNS64 DNS64 server server program program at at (with (with source source IP IP address address PowerDNS 1025 65534 18655 10.0.0.2) to the authoritative DNS server program (listening at DNS64 server listens, respectively. (The port number is (Its next query is for the A record.) Thus BIND is not vulnerable PowerDNS 1025 65534 18655 10.0.0.2)10.0.0.2) to to the the authoritative authoritative DNS DNS server server program program (listening (listening at at Unbound 1024 65535 17467 JUNEport 201853 of • VOLUME) be X included. • NUMBER The2 output file contained only the optional, its default value is 53.) 21 to the “birthday attack”. Unbound 1024 65535 17467 port 53 of ) be included. The output file contained only the Unbound 1024 65535 17467 portsource 53 of port numbers.) be included. As expected,The output the file result contained files onlycontained the The program sends number of AAAA record requests for The results produced by OLDTOTD can be seen in Fig. 10. source port numbers. As expected, the result files contained source port numbers. As expected, the result files contained It sent two equivalent queries for the same resource records 131072 numbers, except for BIND, in the case of which there the 100b0.dns64perf.test domain name, where and 56769, 57025 131072 numbers, except for BIND, in the case of which there (first for AAAA records and then for A records). It can be also 56769, 57025 were 131073 numbers in the file. We have investigated the case should be in the [0, 255] interval. After sending all the queries, 57281, 57537 were 131073 numbers in the file. We have investigated the case observed that the Transaction IDs were incremented by 0x100, 57281, 57537 and found that it was so because BIND also sent a query for the it also receives the replies, but it does not use them for any 57793, 58049 and found that it was so because BIND also sent a query for the as they took the values: 0x7ca9, 0x7da9, 0x7ea9, 0x7fa9. 57793, 58049 IP addresses of the root DNS servers. None of the other purposes. It receives them only to avoid the annoying It is well visible that the consecutive Transaction IDs always IP addresses of the root DNS servers. None of the other It is well visible that the consecutive Transaction IDs always implementations did so. “Destination Unreachable (Port Unreachable)” ICMP error We note that none of them is a serious problem, because increase by 256. And now we give the explanation. As we implementations did so. TOTD does not use caching. Thus no cache poisoning attack increase by 256. And now we give the explanation. As we We have summarized our results in Table 2. BIND, messages. disclosed it in [30], the old version of TOTD generated We have summarized our results in Table 2. BIND, against TOTD is possible. The attacker can at most achieve that disclosed it in [30], the old version of TOTD generated PowerDNS and Unbound follow the guidelines of RFC 5452 The source code of the test program is available from [39]. sequential numbers as Transaction IDs. The increase of 256 is PowerDNS and Unbound follow the guidelines of RFC 5452 sequential numbers as Transaction IDs. The increase of 256 is [13] and choose a source port number randomly from the largest a single client receives forged answer. the result of the facts that the notebook used for testing has an [13] and choose a source port number randomly from the largest The results produced by NEWTOTD can be seen in Fig. 11. the result of the facts that the notebook used for testing has an available range of [1024, 65535]. Both versions of TOTD use Intel CPU, which uses LSB byte order (least significant byte available range of [1024, 65535]. Both versions of TOTD use The concurrently sent multiple equivalent queries The only improvement over OLDTOTD is the proper Intel CPU, which uses LSB byte order (least significant byte source port 53 for all outgoing queries. This is trivially first), whereas the network byte order is MSB (most significant source port 53 for all outgoing queries. This is trivially vulnerability tests were performed in the same testbed as the first), whereas the network byte order is MSB (most significant predictable. As for mtd64ng, what can be seen from Table 2, Transaction ID randomization. byte first). The programmer could have been used the standard predictable. As for mtd64ng, what can be seen from Table 2, previous two measurements. Wireshark (executed on the host We performed two measurements with mtd64ng because of byte first). The programmer could have been used the standard is that the source port number range is [32768, 61000]. What function for the conversion, but omitting it is just a is that the source port number range is [32768, 61000]. What computer under Windows) was used to monitor the behavior of function function for for the the conversion, conversion, but but omitting omitting it itis isju just sta a cannot be seen from the table is that the same source ports are the following reasons. As only one CPU core was assigned to feature and not a bug, as Transaction IDs are just identifiers and cannot be seen from the table is that the same source ports are the DNS64 implementations. We captured the packets on the featurefeature and and not not a bug,a bug, as as Transaction Transaction IDs IDs are are just just identifiers identifiers and and used for querying the AAAA record and the A record for the the virtual machine in the testbed, originally we set the they do not convey any special meaning. For more information used for querying the AAAA record and the A record for the theythey do do not not convey convey any any special special meaning. meaning. For For more more in informationformation same domain name. This is deliberate from the raw about the bug, which randomly caused an unresponsiveness of same domain name. This is deliberate from the raw aboutabout the the bug, bug, which which randomly randomly caused caused an an unresponsiv unresponsivenesseness of of measurement results, we show only the first 6 lines: the old version of TOTD, and for its correction, please refer to measurement results, we show only the first 6 lines: thethe old old version version of of TOTD, TOTD, and and for for its its correction, correction, pl pleaseease refer refer to to 48926 [30], where we have also described the elimination of its 48926 [30],[30], where where we we have have also also described described the the elimination elimination of of its its 48926 vulnerability for Transaction ID prediction attack. 48926 vulnerabilityvulnerability for for Transaction Transaction ID ID prediction prediction attack. attack. 41556 Fig. 7 shows the input correlation and autocorrelation of the 41556 Fig.Fig. 7 7shows shows the the input input correlation correlation and and autocorrelat autocorrelationion of of the the 41556 Transaction IDs of NEWTOTD. They seem to be like noise, 41556 TransactionTransaction IDs IDs of of NEWTOTD. NEWTOTD. They They seem seem to to be be like like no noise,ise, 42713 which is exactly what we expected. 42713 whichwhich is isexactly exactly what what we we expected. expected. 42713 Fig. 8 shows the input correlation and autocorrelation of the 42713 Fig.Fig. 8 8shows shows the the input input correlation correlation and and autocorrelat autocorrelationion of of the the And it is also deliberate from the source code [38]. Although, Transaction IDs of mtd64ng. They are two completely And it is also deliberate from the source code [38]. Although, TransactionTransaction IDs IDs of of mtd64ng. mtd64ng. They They are are two two completel completely y this phenomenon does not mean predictability in the bind identical graphs, as the two CSV files were found also this phenomenon does not mean predictability in the bind identicalidentical graphs, graphs, as as the the two two CSV CSV files files were were found found a lso also spoofing attack model, we recommend the usage of different completely identical. It is visibly the graph of y=x function, spoofing attack model, we recommend the usage of different completelycompletely identical. identical. It It is is visibly visibly the the graph graph of of y= y=x x function, function, source ports for the AAAA and A record queries. because mtd64ng reuses the Transaction ID of the received source ports for the AAAA and A record queries. becausebecause mtd64ng mtd64ng reuses reuses the the Transaction Transaction ID ID of of the the received received It can also be seen from the source code, that mtd64ng query and sends both of its own queries with the same It can also be seen from the source code, that mtd64ng queryquery and and sends sends both both of of its its own own queries queries with with the the sa sameme entrusts the source port selection to the operating system. It can Transaction ID, which is a serious vulnerability. entrusts the source port selection to the operating system. It can TransactionTransaction ID, ID, which which is isa seriousa serious vulnerability. vulnerability. be satisfactory, if the operating system complies with RFC 6056 As we already mentioned, mtd64ng is a result of an ongoing be satisfactory, if the operating system complies with RFC 6056 AsAs we we already already mentioned, mentioned, mtd64ng mtd64ng is isa resulta result of of an an ongoing ongoing [14], but we contend that is safer if source port randomization university project and it not yet ready to be used in production [14], but we contend that is safer if source port randomization universityuniversity project project and and it itnot not yet yet ready ready to to be be used used in in production production is done by the DNS or DNS64 implementation itself. systems [31]. is done by the DNS or DNS64 implementation itself. systemssystems [31]. [31]. As for PowerDNS and Unbound, we have also performed the ULTIPLE QUIVALENT UERIES ULNERABILITY As for PowerDNS and Unbound, we have also performed the VIII. MULTIPLE EQUIVALENT QUERIES VULNERABILITY tests and evaluated the results. All their plots looked like the VIII. MULTIPLE EQUIVALENT QUERIES VULNERABILITY tests and evaluated the results. All their plots looked like the TESTING plots of BIND or NEWTOTD, thus we can state that we found TESTING plots of BIND or NEWTOTD, thus we can state that we found To be able to test, whether the examined DNS64 no signs of Transaction ID predictability. (We omit the four ToTo be be able able to to test, test, whether whether the the examined examined DNS64 DNS64 no signs of Transaction ID predictability. (We omit the four implementations send multiple equivalent queries concurrently, plots, because we see no point in including further four “random implementationsimplementations send send multiple multiple equivalent equivalent queries queries co concurrently,ncurrently, plots, because we see no point in including further four “random we had to modify the test program so that it can send multiple art” images.) wewe had had to to modify modify the the test test program program so so that that it itcan can se sendnd multiple multiple art” images.) queries for the same domain name. queriesqueries for for the the same same domain domain name. name. VII. SOURCE PORT NUMBER RANDOMNESS TESTING VII. SOURCE PORT NUMBER RANDOMNESS TESTING The results of the Transaction ID prediction tests could have TheThe results results of of the the Transaction Transaction ID ID prediction prediction tests tests could could have have been used also for port number randomness tests, but The [35] test program was used as a starting been used also for port number randomness tests, but TheThe [35] [35] test test program program was was used used as as a astarting starting did not include the port numbers in its output. (Its default output point of our new program. Its arguments did not include the port numbers in its output. (Its default output point of our new program. Its arguments contains the same data as the Wireshark screen shown in pointare: of, our, new , and program. . Parameter Its arguments can containscontains the the same same data data as as the the Wireshark Wireshark screen screen show shown n in in are: , , , and . Parameter can are: , , , and . Parameter can 11 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 10 >10 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
INFOCOMMUNICATIONS JOURNAL Methodology for DNS Cache Poisoning Vulnerability 11 Analysis10 of DNS64 Implementations > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITHFig. 9. WiresharkYOUR PAPER capture taken IDENTIFICATION during the birthday attack NUMBER vulnerability (DOUBLECLICK test of BIND. HERE TO EDIT) < Fig. 9. Wireshark capture taken during the birthday attack vulnerability test of BIND. Fig. 12. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 1 working thread. Fig. 12. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 1 working thread.
Fig. 9. Wireshark capture taken during the birthday attack vulnerability test of BIND. 11 Fig. 10. Wireshark capture taken during the birthday> attack REPLACE vulnerability THIS test LINEof OLDTOTD. WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Fig. 10. Wireshark capture taken during the birthday attack vulnerability test of OLDTOTD. Fig.Fig. 13.12. WiresharkWireshark capturecapture takentaken duringduring thethe birthdabirthdayy attackattack vulnerabilityvulnerability testtest ofof mtd64ngmtd64ng withwith 21 workworkinging threads.thread.
We have summarized the results of the three kind of
n order to
Fig. 10. Wireshark capture taken during the birthday attack vulnerability test of OLDTOTD. Fig. 14. Wireshark capture taken during the birthdaserversy attack and vulnerability are currently test of PowerDNS. awaiting for an answer, i
10 Fig. 14. Wireshark capture taken during the birthday attack vulnerability test of PowerDNS.
, D track of the queries sent by mtd64ng to the authoritative DNS IX. S RECOMMENDATIONS AND ISCUSSION
UMMARY
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICKFig. 11. Wireshark HERE capture TO EDIT)taken during < the birthday attack vulnerability test of NEWTOTD. entrally keep
Fig. 12. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 1 working Fig.thread. 13. Wireshark capture taken during the birthday attack workingvulnerability threads. test of mtd64ng However, with it 2will work being necessary threads. to c
Fig. 11. Wireshark capture taken during the birthday attack vulnerability test of NEWTOTD. not stored in a central database, but they are distributed to the attacks.
benefits from the solution that the requests from the clients are birthday
be used to perform multiple tests with a different domain name VMnet1 interface using the capture filter. equivalent queries, thus they are not vulnerable to a more difficult problem, as now the performance of mtd64ng ltiple
be used to perform multiple tests with a different domain name and Fig. 15, respectively. None of them send out mu
inbe each used test. to perform It is for multiple convenience: tests withwhen a multipledifferent tests domain are done,name VMnet1The usual interface command using line the was: capture filter. elimination of the vulnerability to birthday attacks seems to be g. 14
thein each DNS64 test. server It is for may convenience: cache the previously when multiple used domatests arein names done, The usual command line was: The results of PowerDNS and Unbound are shown in Fi
generating Transaction IDs and source port numbers. The
andthe DNS64 it is easier server to may use cache a different the previously one for used a new doma test,in names than development plans of mtd64ng.
of cryptographically secure random number generators [40] for rm
and it is easier to use a different one for a new test, than later, because including caching is among the midte
restarting the DNS64 server. Parameter specifies the number (However, sometimes different values were used for , e.g. vulnerabilities must also be included. We recommend the usage addressed
is not a serious vulnerability,Fig. the 15. problem Wireshark mustcapture be taken during the birthday attack vulnerability test of Unbound.
Fig. 9. Wireshark capture taken during the birthdayofrestarting queries attack the vulnerability to DNS64 be sent. test server. The of BIND. restParameter of the parameters specifies the are number to be 3 instead(However, of 0 sometimesin the case showndifferent in valuesFig. 9.) were used for , e.g.
development plans of mtd64ng, the protection against all three g, thus it
interpretedof queries to as be that sent. of The theFig. rest original 11. Wireshark of the test parameters capture program, taken a duringre that to the is,be birthda 3 yinsteadThe attack resultsvulnerability of 0 in produced the test case of NEWTOTD. shown by BIND in Fig. can 9.) be seen in Fig. 9. Although mtd64ng currentlyFig. does 14. Wireshark not support capture cachin taken during the birthday attack vulnerability test of PowerDNS.
As the implementation of caching is included in the midterm request. separate AAAA and A record requests for each client
interpreted, as that of and the original specify test the program, timeout value that is,of AlthoughThe results we sent produced two queries by for BIND the AAAA can be record seen of in the Fig. same 9. number of working threads of mtd64ng to 1. Due to this measurements in Table 3. As for BIND, PowerDNS, and in their cases. 64ng sends Fig. 13. Wireshark capture taken during the birthday attack vulnerability test of mtd64ngnumbertwo threads. with of 2 workworking Theing results threads. threads in Fig. of 13 mtd64ng reveal that to mtd 1. Due to this measurements in Table 3. As for BIND, PowerDNS, and
the receive, function, the and IPv6 address specify (or the host timeout name) value of the of domainAlthough name, we sent BIND two sent queries only for one the request AAAA to record the auth of theoritative same setting, mtd64ng serialized the processing of the requests from Unbound, we have not found any vulnerabilities that could lead do not implement caching, thus cache poisoning is not possible t also with
be used to perform multiple tests with a different domain name VMnet1 interface using the capture filter. setting,use multiple mtd64ng threads, serialized therefore the processingwe executed of thethe tesrequests from Unbound, we have not found any vulnerabilities that could lead
DNS64the receive server function, to be testedthe IPv6 and address the port (or number, host nam where) ofe the DNSdomain server name, for BIND the AAAA sent only record one ofrequest the given to the domain authoritative name. our test program, as shown in Fig. 12. However, the DNS64 to cache poisoning. Although TOTD and mtd64ng have several vulnerabilities that could lead to cache poisoning, they rs should in each test. It is for convenience: when multiple tests are done, The usual command line was: ourserver test of program, a large network as shown with in aFig. high 12. number However, of use the DNS64 to cache poisoning. Although TOTD and mtd64ng have
DNS64 server server to listens, be tested respectively. and the port (The number, port numbe wherer the is (ItsDNS next server query for is thefor theAAAA A record.) record Thus of the BIND given is notdomain vulnerable name. server of a large network with a high number of users should several vulnerabilities that could lead to cache poisoning, they to cache poisoning. Although TOTD and mtd64ng have DNS64 the DNS64 server may cache the previously used domain names serverour test of program, a large network as shown with in aFig. high 12. number However, of use thers should several vulnerabilities that could lead to cache poisoning, they
optional,DNS64 serverits default listens, value respectively.is 53.) (The port number is to(Its the next “birthday query is attack”. for the A record.) Thus BIND is not vulnerable use multiple threads, therefore we executed the test also with do not implement caching, thus cache poisoning is not possible Unbound, we have not found any vulnerabilities that could lead requests from and it is easier to use a different one for a new test, than usesetting, multiple mtd64ng threads, serialized therefore the processingwe executed of thethe test also with do not implement caching, thus cache poisoning is not possible
optional,The program its default sends value number is 53.) of AAAA record requests for to Thethe “birthdayresults produced attack”. by OLDTOTD can be seen in Fig. 10. two threads. The results in Fig. 13 reveal that mtd64ng sends in their cases. measurements in Table 3. As for BIND, PowerDNS, and this restarting the DNS64 server. Parameter specifies the number (However, sometimes different values were used for , e.g. twonumber threads. of working The results threads in Fig. of 13 mtd64ng reveal that to mtd 1. Due64ng to sends in their cases. The program sends number of AAAA record requests for It sentThe results two equivalent produced queriesby OLDTOTD for the samecan be resourc seen ine Fig. records 10. theof queries 100b0.dns64perf.test to be sent. The rest domain of the name, parameters where are and to be 3 instead of 0 in the case shown in Fig. 9.) separate AAAA and A record requests for each client request. As the implementation of caching is included in the midterm shouldthe 100b0.dns64perf.test be in the [0, 255] interval. domain After name, sending where all the queries, and (firstIt sent for two AAAA equivalent records queries and then for for the A samerecords). resourc It cane recordsbe also Although mtd64ng currently does not support caching, thus it development plans of mtd64ng, the protection against all three
interpreted as that of the original test program, that is, The results produced by BIND can be seen in Fig. 9. Although mtd64ng currentlyFig. does 15. Wiresharknot support capture cachin takeng, during thus theit birthdadevelopmenty attack vulnerability plans of test mtd64ng, of Unbound. the protection against all three
Fig. 10. Wireshark capture taken during the birthday attack vulnerability test of OLDTOTD. observed(first for AAAAthat the recordsTransaction and then IDs forwere A incrementedrecords). It can by 0x100,be also y attack vulnerability test of Unbound. itshould also receivesbe in, the the[0, 255] replies, and interval. but it After specify does sendingnot the use timeout a tllhem the valuequeries, for any of Although we sent two queries for the AAAA record of the same is not a serious vulnerability,Fig. the 15. problem Wireshark mustcapture be taken addressed during the birthdavulnerabilities must also be included. We recommend the usage
asobserved they took that the the values: Transaction 0x7ca9,Fig. IDs 14. 0x7da9, Wiresharkwere incremented 0x7ea9, capture 0xtaken7fa9. by during 0x100, the birthday attack vulnerability test of PowerDNS. purposes.itthe also receive receives It function, receives the replies, the them IPv6 but only addressit does to (ornot avoid host use thet namhem annoyie) for of any theng domain name, BIND sent only one request to the authoritative later, because including caching is among the midterm of cryptographically secure random number generators [40] for as Wethey notetook thatthe values: none of 0x7ca9, them is0x7da9, a serious 0x7ea9, problem, 0x7fa9. bec ause “Destinationpurposes.DNS64 server It Unreachable receives to be tested them (Port and only the Unreachable)” to port avoid number, the ICMP wher annoyi e e rror theng DNS server for the AAAA record of the given domain name. numberdevelopment of working plans of threadsmtd64ng. of mtd64ng to 1. Due to this generatingmeasurements Transaction in Table IDs 3. As and for source BIND, port PowerDNS, numbers. Theand TOTDWe notedoes thatnot use none caching. of them Thus is a no serious cache problem,poisoning bec attackause messages.“DestinationDNS64 server Unreachable listens, respectively. (Port Unreachable)” (The port ICMP numbe errror is (Its next query is for the A record.) Thus BIND is not vulnerable setting,The results mtd64ng of PowerDNS serialized theand processing Unbound areof theshown requests in Fi g.from 14 eliminationUnbound, we of have the vulnerability not found any to vulnerabilities birthday attack thats seems could to lead be againstTOTD TOTDdoes not is possible.use caching. The Thusattacker no cancache at mostpoisoning achieve attack that messages.optional,The source its default code of value the testis 53.) program is available from [39]. to the “birthday attack”. ourand test Fig. program, 15, respectively. as shown None in Fig. of 12. them However, send out the muDNS64ltiple ato more cache difficult poisoning. problem, Although as now the TOTD performance and mtd64ng of mtd64ng have The source code of the test program is available from [39]. aagainst single TOTDclient receivesis possible. forged The answer. attacker can at most achieve that The sourceprogram code sends of the number test program of AAAA is available record frrequestsom [39]. for The results produced by OLDTOTD can be seen in Fig. 10. serverequivalent of a queries,large network thus theywith area high not number vulnerable of use to rs birthday should benefitsseveral vulnerabilities from the solution that that could the lead requests to cache from po theisoning, clients they are a singleThe results client producedreceives forged by NEWTOTD answer. can be seen in Fig. 11. It sent two equivalent queries for the same resource records useattacks. multiple threads, therefore we executed the test also with notdo not stored implement in a central caching, database, thus cache but they poisoning are dist isributed not possible to the theThe 100b0.dns64perf.test concurrently sent domain multiple name, equivalent where queries and TheThe only results improvement produced by NEWTOTD over OLDTOTD can be seen is the in Fig. proper 11.
(first for AAAA records and then for A records). It can be also two threads. The results in Fig. 13 reveal that mtd64ng sends workingin their cases. threads. However, it will be necessary to centrally keep should be in the [0, 255] interval. After sending all the queries, vulnerabilityThe concurrently tests were sentperformed multiple in the equivalentsame testbed queriesas the TransactionThe only ID improvement randomization. over OLDTOTD is the proper separate AAAA and A record requests for each client request. As the implementation of caching is included in the midterm
it also receives the replies, but it does not use them for any observed that the Transaction IDs were incremented by 0x100, IX. SUMMARY, RECOMMENDATIONS AND DISCUSSION track of the queries sent by mtd64ng to the authoritative DNS y attack vulnerability test of PowerDNS. previousvulnerability two testsmeasurements. were performed Wireshark in the (executed same test onbed the as host the TransactionWe performed ID randomization. two measurements with mtd64ng because of Although mtd64ng currentlyFig. does 14. Wireshark not support capture cachin takeng, during thus the it birthdadevelopment plans of mtd64ng, the protection against all three
purposes. It receives them only to avoid the annoyi ng as they took the values: 0x7ca9,Fig. 15.0x7da9, Wireshark 0x7ea9, capture 0x taken7fa9. during the birthday attack vulnerability testWe of haveUnbound. summarized the results of the three kind of servers and are currently awaiting for an answer, in order to computerprevious twounder measurements. Windows) was Wireshark used to monitor (executed the behon taviorhe host of theWe following performed reasons. two measurements As only one CPU with coremtd64ng was ass becauseigned toof We have summarized the results of the three kind of Fig. 11. Wireshark capture taken during the birthday attack vulnerability test of NEWTOTD. We note that none of them is a serious problem, because is not a serious vulnerability, the problem must be addressed vulnerabilities must also be included. We recommend the usage the“Destinationcomputer DNS64 under implementations. Unreachable Windows) was (Port We used captured Unreachable)” to monitor the thepackets ICMP behavior on e rrorthe of the following reasons. As only one CPU core was assigned to theTOTD does virtual not use machine caching. in theThus testbed, no cache originally poisoning we setattack the later, because including caching is among the midterm of cryptographically secure random number generators [40] for messages.the DNS64 implementations. We captured the packets on the numberthe of virtual working machine threads in ofthe mtd64ng testbed, originally to 1. Due we toset this the measurements in Table 3. As for BIND, PowerDNS, and against TOTD is possible. The attacker can at most achieve that development plans of mtd64ng. generating Transaction IDs and source port numbers. The be used to perform multiple tests with a different domain name VMnet1The source interface code using of the the test program iscapture available filter. fr om [39]. setting, mtd64ng serialized the processing of the requests from Unbound, we have not found any vulnerabilities that could lead a single client receives forged answer. The results of PowerDNS and Unbound are shown in Fig. 14 elimination of the vulnerability to birthday attacks seems to be in each test. It is for convenience: when multiple tests are done, The usual command line was: our test program, as shown in Fig. 12. However, the DNS64 to cache poisoning. Although TOTD and mtd64ng have The results produced by NEWTOTD can be seen in Fig. 11. and Fig. 15, respectively. None of them send out multiple a more difficult problem, as now the performance of mtd64ng the DNS64 server may cache the previously used domain names server of a large network with a high number of users should several vulnerabilities that could lead to cache poisoning, they The concurrently sent multiple equivalent queries The only improvement over OLDTOTD is the proper equivalent queries, thus they are not vulnerable to birthday benefits from the solution that the requests from the clients are and it is easier to use a different one for a new test, than use multiple threads, therefore we executed the test also with do not implement caching, thus cache poisoning is not possible
vulnerability tests were performed in the same testbed as the Transaction ID randomization. attacks. not stored in a central database, but they are distributed to the
y attack vulnerability test of mtd64ng with 2 working threads. restarting the DNS64 server. Parameter specifies the number (However, sometimes different values were used for , e.g. two threads. The results in Fig. 13 reveal that mtd64ng sends in their cases. Fig. 13. Wireshark capture taken during the birthda
previous two measurements. Wireshark (executed on the host We performed two measurements with mtd64ng because of working threads. However, it will be necessary to centrally keep of queries to be sent. The rest of the parameters are to be 3 instead of 0 in the case shown in Fig. 9.) separate AAAA and A record requests for each client request. As the implementation of caching is included in the midterm computer under Windows) was used to monitor the behavior of the following reasons. As only one CPU core was assigned to IX. SUMMARY, RECOMMENDATIONS AND DISCUSSION track of the queries sent by mtd64ng to the authoritative DNS interpreted as that of the original test program, that is, The results produced by BIND can be seen in Fig. 9. Although mtd64ng currently does not support caching, thus it development plans of mtd64ng, the protection against all three the DNS64 implementations. We captured the packets on the servers and are currently awaiting for an answer, in order to the virtual machine in the testbed, originally we set the We have summarized the results of the three kind of , and specify the timeout value of Although we sent two queries for the AAAA record of the same is not a serious vulnerability, the problem must be addressed vulnerabilities must also be included. We recommend the usage the receive function, the IPv6 address (or host name) of the domain name, BIND sent only one request to the authoritative later, because including caching is among the midterm of cryptographically secure random number generators [40] for DNS64 server to be tested and the port number, where the DNS server for the AAAA record of the given domain name. development plans of mtd64ng. generating Transaction IDs and source port numbers. The DNS64 server listens, respectively. (The port number is (Its next query is for the A record.) Thus BIND is not vulnerable The results of PowerDNS and Unbound are shown in Fig. 14 elimination of the vulnerability to birthday attacks seems to be optional, its default value is 53.) to the “birthday attack”. and Fig. 15, respectively. None of them send out multiple a more difficult problem, as now the performance of mtd64ng 22The results produced by OLDTOTD can be seen in Fig. 10. JUNE 2018 • VOLUME X • NUMBER 2 The program sends number of AAAA record requests for equivalent queries, thus they are not vulnerable to birthday benefits from the solution that the requests from the clients are It sent two equivalent queries for the same resource records attacks. not stored in a central database, but they are distributed to the
the 100b0.dns64perf.test domain name, where and
y attack vulnerability test of mtd64ng with 1 working thread.
should be in the [0, 255] interval. After sending all the queries, (first for AAAA records and then for A records). It can be also working threads. However, it will be necessaryFig. 12. Wireshark to centrally capture keep taken during the birthda it also receives the replies, but it does not use them for any observed that the Transaction IDs were incremented by 0x100, IX. SUMMARY, RECOMMENDATIONS AND DISCUSSION track of the queries sent by mtd64ng to the authoritative DNS purposes. It receives them only to avoid the annoying as they took the values: 0x7ca9, 0x7da9, 0x7ea9, 0x7fa9. We have summarized the results of the three kind of servers and are currently awaiting for an answer, in order to “Destination Unreachable (Port Unreachable)” ICMP error We note that none of them is a serious problem, because messages. TOTD does not use caching. Thus no cache poisoning attack The source code of the test program is available from [39]. against TOTD is possible. The attacker can at most achieve that a single client receives forged answer. The results produced by NEWTOTD can be seen in Fig. 11. The concurrently sent multiple equivalent queries The only improvement over OLDTOTD is the proper
vulnerability tests were performed in the same testbed as the Transaction ID randomization.
previous two measurements. Wireshark (executed on the host We performed two measurements with mtd64ng because of
NUMBER (DOUBLECLICK HERE TO EDIT) <
computer under Windows) was used to monitor the behavior of the following reasons. As only one CPU core was assigned to > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION the DNS64 implementations. We captured the packets on the 11 the virtual machine in the testbed, originally we set the 11 >11 REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 10 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
INFOCOMMUNICATIONS JOURNAL 11 Methodology for DNS Cache Poisoning Vulnerability 11 10 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICKAnalysis of DNS64 HERE ImplementationsTO EDIT) < > REPLACE THISFig. LINE12. Wireshark WITH capture YOUR taken PAPER during theIDENTIFICATION birthday attack vulnerability NUMBER test of mtd64ng (DOUBLECLICK with 1 working HEREthread. TO EDIT) < > REPLACE THIS LINE WITHFig. 9. WiresharkYOUR PAPER capture taken IDENTIFICATION during the birthday attack NUMBER vulnerability (DOUBLECLICK test of BIND. HERE TO EDIT) < Fig. 12. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 1 working thread. Fig. 12. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 1 working thread.
11 Fig. 9. Wireshark capture taken during the birthday attack vulnerability> test REPLACE of BIND. THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
Fig. 13. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 2 working threads. Fig. 10. Wireshark capture taken during the birthday attack vulnerability test of OLDTOTD. Fig. 12. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 1 working thread. Fig.Fig. 13.12. WiresharkWireshark capturecapture takentaken duringduring thethe birthdaybirthday attackattack vulnerabilityvulnerability testtest ofof mtd64ngmtd64ng withwith 21 workingworking threads.thread.
Fig. 14. Wireshark capture taken during the birthday attack vulnerability test of PowerDNS.
We have summarized the results of the three kind of servers and are currently awaiting for an answer, in order to
Fig. 10. Wireshark capture taken during the birthday attack vulnerability test of OLDTOTD. Fig. 14. Wireshark capture taken during the birthday attack vulnerability test of PowerDNS.
Fig. 14. Wireshark capture taken during the birthda y attack vulnerability test of PowerDNS.
, D track of the queries sent by mtd64ng to the authoritative DNS IX. S RECOMMENDATIONS AND ISCUSSION
Fig. 12. Wireshark capture taken during the birthday attack vulnerabilityUMMARY test of mtd64ng with 1 working thread.
Fig. 11. Wireshark capture taken during the birthday attack vulnerability test of NEWTOTD. Fig. 13. Wireshark capture taken during the birthday attack vulnerability test of mtd64ng with 2 working threads. entrally keep
Fig. 13. Wireshark capture taken during the birthday attack workingvulnerability threads. test of mtd64ng However, with it 2will working be necessary threads. to c
not stored in a central database, but they are distributed to the attacks.
benefits from the solution that the requests from the clients are birthday
be used to perform multiple tests with a different domain name VMnet1 interface using the capture filter. equivalent queries, thus they are not vulnerable to a more difficult problem, as now the performance of mtd64ng ltiple
in each test. It is for convenience: when multiple tests are done, The usual command line was: and Fig. 15, respectively. None of them send out mu
elimination of the vulnerability to birthday attacks seems to be
the DNS64 server may cache the previously used domain names The results of PowerDNS and Unbound are shown in Fig. 14
generating Transaction IDs and source port numbers. The
and it is easier to use a different one for a new test, than development plans of mtd64ng.
of cryptographically secure random number generators [40] for rm later, because including cachingFig. 15. Wireshark is among capture thetaken midteduring the birthday attack vulnerability test of Unbound.
restarting the DNS64 server. Parameter specifies the number (However, sometimes different values were used for , e.g. vulnerabilities must also be included. We recommend the usage addressed
is not a serious vulnerability,Fig. the 15. problem Wireshark mustcapture be taken during the birthday attack vulnerability test of Unbound.
of queries to be sent. The rest of the parameters are to be 3 instead of 0 in the case shown in Fig. 9.) Fig. 14. Wireshark capture taken during the birthday attack vulnerability test of PowerDNS.
development plans of mtd64ng, the protection against all three g, thus it Fig. 11. Wireshark capture taken during the birthday attack vulnerability test of NEWTOTD. Although mtd64ng currentlyFig. does 14. Wireshark not support capture cachin taken during the birthday attack vulnerability test of PowerDNS.
interpreted as that of the original test program, that is, The results produced by BIND can be seen in Fig. 9. number of working threads of mtd64ng to 1. Due to this measurements in Table 3. As for BIND, PowerDNS, and As the implementation of caching is included in the midterm request. Fig. 13. Wireshark capture taken during the birthday attack separatevulnerability AAAA test of mtd64ngand A record with 2 workingrequests threads. for each client
, and specify the timeout value of Although we sent two queries for the AAAA record of the same setting,number mtd64ng of working serialized threads the of processing mtd64ng of to the 1. requests Due to from this Unbound,measurements we have in not Table found 3. any As vulnerabilities for BIND, PowerDNS, that could lead and in their cases. numbertwo threads. of working The results threads in Fig. of 13 mtd64ng reveal that to mtd64ng 1. Due to sends this measurements in Table 3. As for BIND, PowerDNS, and
the receive function, the IPv6 address (or host name) of the domain name, BIND sent only one request to the authoritative oursetting, test mtd64ngprogram, serializedas shown thein Fig.processing 12. However, of the requests the DNS64 from toUnbound, cache poisoning.we have not Althoughfound any TOTDvulnerabilities and mtd64ng that could have lead do not implement caching, thus cache poisoning is not possible t also with be used to perform multiple tests with a different domain name VMnet1 interface using the capture filter. setting,use multiple mtd64ng threads, serialized therefore the processingwe executed of thethe tesrequests from Unbound, we have not found any vulnerabilities that could lead
DNS64 server to be tested and the port number, where the DNS server for the AAAA record of the given domain name. serverour test of program,a large network as shown with in aFig. high 12. number However, of users the DNS64should severalto 12 cache vulnerabilities poisoning. that Although could lead TOTD to cache and mtd64ngpoisoning, havethey several vulnerabilities that could lead to cache poisoning, they in each test. It is for convenience: when multiple tests are done, The usual command line was: ourserver test of program, a large network as shown with in aFig. high 12. number However, of users the DNS64 should to cache poisoning. Although TOTD and mtd64ng have
DNS64 server listens, respectively. (The port number is (Its next query is for the A record.) Thus BIND is not vulnerable useserver multiple of a large threads, network therefore with wea high executed number the of tes userst also should with doseveral >not REPLACE implement vulnerabilities THIS caching, LINEthat thuscould WITH cache lead YOUR poisoningto cache PAPER po isisoning, not IDENTIFICATION possible they NUMBER (DOUBLECLICK HERE TO EDIT) < to cache poisoning. Although TOTD and mtd64ng have the DNS64 server may cache the previously used domain names serverour test of program, a large network as shown with in aFig. high 12. number However, of users the DNS64 should several vulnerabilities that could lead to cache poisoning, they
optional, its default value is 53.) to the “birthday attack”. twouse threads.multiple Thethreads, results therefore in Fig. 13we revealexecuted that the mtd64ng test also sends with indo their not implementcases. caching, thus cache poisoning is not possible Unbound, we have not found any vulnerabilities that could lead and it is easier to use a different one for a new test, than usesetting, multiple mtd64ng threads, serialized therefore the processingwe executed of thethe tesrequestst also fromwith do not implement caching, thus cache poisoning is not possible
The program sends number of AAAA record requests for The results produced by OLDTOTD can be seen in Fig. 10. separatetwo threads. AAAA The and results A record in Fig. requests 13 reveal for thateach mtd64ng client request. sends in Astheir the cases. implementation of caching is includedTable in 3. the Summary midterm of the Vulnerability Test Results measurements in Table 3. As for BIND, PowerDNS, and this restarting the DNS64 server. Parameter specifies the number (However, sometimes different values were used for , e.g. twonumber threads. of working The results threads in Fig. of 13 mtd64ng reveal that to mtd64ng 1. Due to sends in their cases. It sent two equivalent queries for the same resource records theof queries 100b0.dns64perf.test to be sent. The rest domain of the name, parameters where are and to be 3 instead of 0 in the case shown in Fig. 9.) Althoughseparate AAAA mtd64ng and currently A record does requests not support for each cachin clientg, request. thus it developmentAs the implementation plans of mtd64ng, of caching the protection is included against in the midtermall three (first for AAAA records and then for A records). It can be also Fig. 15. Wireshark capture taken during the birthda y attack vulnerability test of Unbound. Attack Type shouldinterpreted be in asthe that[0, 255] of interval. the original After testsending program, all the queries, that is, The results produced by BIND can be Fig. seen 14. Wireshark in Fig. 9.capture taken during the birthdaisAlthough noty attack a serious vulnerability mtd64ng vulnerability, test currently of PowerDNS.Fig. doesthe 15. problem Wiresharknot support must capture cachin be taken addressedg, during thus theit birthdavulnerabilitiesdevelopmentDNS64y attack Implementation vulnerability plans must ofalso test mtd64ng, ofbe Unbound. included. the protectionWe recommend against the all usage three
observed that the Transaction IDs were incremented by 0x100, Transaction ID Prediction Source Port Number Prediction Multiple Equivalent Queries DNS Cache Poisoning y attack vulnerability test of Unbound. it also receives the replies, but it does not use them for any Fig. 15. Wireshark capture taken during the birthda , and specify the timeout value of Although we sent two queries for the AAAA record of the same later,is not becausea serious includingvulnerability, caching the problem is among must thebe addressed midterm ofvulnerabilities cryptographically must alsosecure be randomincluded. number We recommend generators the [40] usage for
as they took the values: 0x7ca9, 0x7da9, 0x7ea9, 0x7fa9. BIND 9.9.5 no problem found no problem found protected no problem found purposes.the receive It function, receives the them IPv6 only address to (or avoid host the nam annoyie) of theng domain name, BIND sent only one request to the authoritative developmentnumberlater, because of working plans including of threadsmtd64ng. caching of mtd64ng is among to 1. the Due midte to thisrm generatingofmeasurements cryptographically Transaction in Table secure IDs 3. random As and for source number BIND, port generators PowerDNS, numbers. [40] The andfor We note that none of them is a serious problem, because number of working threads of mtd64ng to 1. Due to this measurementsTOTD 1.5.2 in Table 3. As vulnerable for BIND, PowerDNS, vulnerable and vulnerable not applicable “DestinationDNS64 server Unreachable to be tested (Port and the Unreachable)” port number, ICMP wher e e rror the DNS server for the AAAA record of the given domain name. developmentsetting,The results mtd64ng plansof PowerDNS serialized of mtd64ng. theand processing Unbound are of theshown requests in Fig. from 14 eliminationgeneratingUnbound, we of Transaction havethe vulnerability not found IDs any and to vulnerabilitiesbirthday source portattacks that numbers. seems could to lead The be TOTD does not use caching. Thus no cache poisoning attack setting, mtd64ng serialized the processing of the requests from Unbound, we have not found any vulnerabilities that could lead messages.DNS64 server listens, respectively. (The port number is (Its next query is for the A record.) Thus BIND is not vulnerable andourThe test Fig. results program,15, respectively.of PowerDNS as shown None andin Fig. Unbound of 12. them However, are send shown out the in mu DNS64Fig.ltiple 14 aeliminationto moreTOTD cache difficult 1.5.3 poisoning. of the problem, vulnerability Although as now to the TOTDprotected birthday performance and attacks mtd64ng of seems mtd64ng to havevulnerable be vulnerable not applicable against TOTD is possible. The attacker can at most achieve that our test program, as shown in Fig. 12. However, the DNS64 to cache poisoning. Although TOTD and mtd64ng have optional,The source its default code of value the testis 53.) program is available from [39]. to the “birthday attack”. equivalentandserver Fig. of 15,a queries,large respectively. network thus they with None area high of not them number vulnerable send of outusers to birthday mu shouldltiple benefitsaseveral moremtd64ng difficultvulnerabilitiesfrom 1.1.0 the problem, solution that asthat could now the vulnerablethelead requests performance to cache from po the isoning,of clients mtd64ng they vulnerableare vulnerable not applicable a single client receives forged answer. attacks.equivalentserver of a queries,large network thus theywith area high not number vulnerable of users to birthday should notbenefitsseveral stored vulnerabilities from in a the central solution database,that that could the but lead requests they to cacheare from distributed po theisoning, clients to they theare The program sends number of AAAA record requests for The results produced by OLDTOTD can be seen in Fig. 10. equivalentuse multiple queries, threads, thus therefore they arewe notexecuted vulnerable the tes tot also birthday with benefitsdoPowerDNS not implement from 3.6.2 the solutioncaching, that thus nothe cache problem requests poisoning found from isthe not clients possibleno problem are found protected no problem found The results produced by NEWTOTD can be seen in Fig. 11. attacks.use multiple threads, therefore we executed the test also with workingnotdo not stored implement threads. in a central However, caching, database, itthus will cache butbe necessary they poisoning are distributedto cisentrally not possible to keep the the 100b0.dns64perf.test domain name, where and It sent two equivalent queries for the same resource records attacks.two threads. The results in Fig. 13 reveal that mtd64ng sends notinUnbound their stored cases. 1.6.0 in a central database,no problembut they found are distributedno to problem the found protected no problem found The concurrently sent multiple equivalent queries The only improvement over OLDTOTD is the proper two threads. The results in Fig. 13 reveal that mtd64ng sends in their cases.
(first for AAAA records and then for A records). It can be also separateIX. S UMMARYAAAA and, RECOMMENDATIONS A record requests ANDfor each DISCUSSION client request. trackworkingAs of the the threads. implementation queries However, sent by of itmtd64ng caching will be necessaryis to included the author to in centrally itativethe midterm DNS keep should be in the [0, 255] interval. After sending all the queries, vulnerability tests were performed in the same testbed as the Transaction ID randomization. Fig. 15. Wireshark capture taken during the birthdaseparatey attack AAAA vulnerability and testA recordof Unbound. requests for each client request. As the implementation of caching is included in the midterm
it also receives the replies, but it does not use them for any observed that the Transaction IDs were incremented by 0x100, AlthoughWeIX. haveSUMMARY mtd64ng summarized, RECOMMENDATIONS currently the does results not support ofAND the D ISCUSSION cachin three g, kind thus of it serverstrackdevelopment of andthe queries are plans currently of sent mtd64ng, by awaiting mtd64ng the forprotection to an the answer, author against itativein orderall DNSthree to
y attack vulnerability test of PowerDNS. previous two measurements. Wireshark (executed on the host We performed two measurements with mtd64ng because of Although mtd64ng currentlyFig. does 14. Wireshark not support capture cachin takeng, during thus the it birthdaeliminatedevelopment the plans possibility of mtd64ng, of sending the protection out multiple against equivalent all three [2] G. Lencse, Y. Kadobayashi, “Survey of IPv6 transition
purposes. It receives them only to avoid the annoying as they took the values: 0x7ca9, 0x7da9, 0x7ea9, 0x7fa9. is Wenot a have serious summarized vulnerability, the the results problem of themust three be addressed kind of serversvulnerabilities and are must currently also be awaiting included. for We an recommend answer, in the order usage to We have summarized the results of the three kind of computer under Windows) was used to monitor the behavior of the following reasons. As only one CPU core was assigned to is not a serious vulnerability, the problem must be addressed queriesvulnerabilities concurrently. must also be included. We recommend the usage technologies for security analysis”, IEICE Technical Committee “Destination Unreachable (Port Unreachable)” ICMP error We note that none of them is a serious problem, because later, because including caching is among the midterm of cryptographically secure random number generators [40] for the DNS64 implementations. We captured the packets on the the virtualnumber machine of in workingthe testbed, threads originally of mtd64ng we set the to 1. Due to this measurementslater, because in including Table 3. caching As for is BIND, among PowerDNS, the midte andrm of Wecryptographically note that all the secure examined random DNS64 number implementations generators [40] arefor on Internet Architecture (IA) Workshop, Tokyo Japan, Aug. 28, messages. TOTD does not use caching. Thus no cache poisoning attack development plans of mtd64ng. generating Transaction IDs and source port numbers. The 2017, vol. 117, no. 187, pp. 19–24. setting, mtd64ng serialized the processing of the requests from Unbound,development we planshave notof mtd64ng. found any vulnerabilities that could lead freegenerating software Transaction [25] (also IDs called and open source source port [26]), numbers. thus their The The source code of the test program is available from [39]. against TOTD is possible. The attacker can at most achieve that The results of PowerDNS and Unbound are shown in Fig. 14 elimination of the vulnerability to birthday attacks seems to be [3] M. Georgescu, H. Hazeyama, T. Okuda, Y. Kadobayashi, and S. our test program, as shown in Fig. 12. However, the DNS64 to The cache results poisoning. of PowerDNS Although and Unbound TOTD and are shown mtd64ng in Fig. have 14 elimination of the vulnerability to birthday attacks seems to be a single client receives forged answer. and Fig. 15, respectively. None of them send out multiple sourcea more codedifficult may problem, also be asstudied, now the as performance we did it in ofth mtd64nge case of Yamaguchi, “The STRIDE towards IPv6: A comprehensive server of a large network with a high number of users should severaland Fig. vulnerabilities 15, respectively. that could None lead of themto cache send po isoning, out multiple they a more difficult problem, as now the performance of mtd64ng The results produced by NEWTOTD can be seen in Fig. 11. equivalent queries, thus they are not vulnerable to birthday TOTDbenefits [30]. from The the solutionsignificance that ofthe our requests testing from method the clients is that are it threat model for IPv6 transition technologies”, use multiple threads, therefore we executed the test also with doequivalent not implement queries, caching, thus they thus arecache not poisoning vulnerable is not to birthdaypossible benefits from the solution that the requests from the clients are The concurrently sent multiple equivalent queries The only improvement over OLDTOTD is the proper attacks. maynot stored also be in useda central for closeddatabase, source but theysoftware, are distributed or in the tocases the two threads. The results in Fig. 13 reveal that mtd64ng sends inattacks. their cases. not stored in a central database, but they are distributed to the , Rome, Feb. 2016. DOI: 10.13140/RG.2.1.2781.6085
vulnerability tests were performed in the same testbed as the Transaction ID randomization. whenworking the threads. subject However,of the study it willalso be includes necessary the toint ceractionentrally keepwith separate AAAA and A record requests for each client request. As the implementationFig. 13. ofWireshark caching capture is included taken during in the the midtermbirthday attack the workingvulnerability random threads. test number of mtd64ng However, generator with it 2will ofworking the be operatingnecessary threads. systemto centrally. keep [4] M. Bagnulo, A Sullivan, P. Matthews and I. Beijnum, “DNS64:
previous two measurements. Wireshark (executed on the host We performed two measurements with mtd64ng because of IX. SUMMARY, RECOMMENDATIONS AND DISCUSSION track of the queries sent by mtd64ng to the authoritative DNS DNS extensions for network address translation from IPv6 clients Although mtd64ng currently does not support caching, thus it development plans of mtd64ng, the protection against all three computer under Windows) was used to monitor the behavior of the following reasons. As only one CPU core was assigned to IX. SUMMARY, RECOMMENDATIONS AND DISCUSSION trackThe of very the samequeries framework sent by mtd64ng could be to used the forauthor theitative analysis DNS of is not a serious vulnerability, the problem must be addressed vulnerabilitiesWe have summarized must also be theincluded. results We of recommend the three the kind usage of servers and are currently awaiting for an answer, in order to to IPv4 servers”, RFC 6147, Apr. 2011. DOI: 10.17487/rfc6147 the DNS64 implementations. We captured the packets on the NAT64servers gateways. and are currently awaiting for an answer, in order to the virtuallater, machine because in the testbed, including originally caching we is set among the the midterm of Wecryptographically have summarized secure therandom results number of thegenerators three kind[40] for of [5] M. Bagnulo, P. Matthews and I. Beijnum, “Stateful NAT64: Network address and protocol translation from IPv6 clients to development plans of mtd64ng. X. CONCLUSION IPv4 servers”, IETF RFC 6146, Apr. 2011. DOI: The results of PowerDNS and Unbound are shown in Fig. 14 10.17487/rfc6146 and Fig. 15, respectively. None of them send out multiple We have shown that DNS cache poisoning may be a crucial [6] G. Lencse, Y. Kadobayashi, “Methodology for the identification equivalent queries, thus they are not vulnerable to birthday vulnerability of DNS64 servers and we have given an of potential security issues of different IPv6 transition attacks. JUNE 2018 • VOLUME X • NUMBER 2 introduction to the three main components of DNS cache23 technologies: Threat analysis of DNS64 and stateful NAT64”, poisoning vulnerability, namely Transaction ID prediction, , vol. 77, no. 1, pp. 397411, August 1,
source port number prediction, and a birthday paradox based 2018, DOI: 10.1016/j.cose.2018.04.012
y attack vulnerability test of mtd64ng with 1 working thread. IX. SUMMARY, RECOMMENDATIONS AND DISCUSSION Fig. 12. Wireshark capture taken during the birthda
attack, which is possible if a DNS or DNS64 server sends out [7] S. Son and V. Shmatikov, “The hitchhiker’s guide to DNS cache We have summarized the results of the three kind of poisoning”, in multiple equivalent queries concurrently. After surveying the available test tools for DNS cache , Singapore, Sep. 7–9, 2010, pp. 466–483, DOI: poisoning vulnerability analysis and pointing out that they are 10.1007/9783642161612_27 not suitable for our purposes, we have designed a methodology [8] G. Lencse and Y. Kadobayashi, “Testbed for security analysis of and implemented it in a testbed, which can be used for the the DNS64 IPv6 transition technology in virtual environment”, systematic testing of DNS or DNS64 implementations, whether IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Oct. 13, 2017, , vol. 117, no. 239, they are susceptible to the above mentioned three pp. 1924.
vulnerabilities. [9] G. Lencse and Y. Kadobayashi, “Benchmarking DNS64 We have selected BIND, PowerDNS, Unbound two versions Implementations: Theory and Practice”,
, vol. 127, no. 1, pp. 6174, September 1, 2018, NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATIONof TOTD, and mtd64ng for testing and also presented their
DOI: 10.1016/j.comcom.2018.05.005 11 setup. We have carried out their testing concerning the three possible components of the DNS cache poisoning vulnerability. [10]R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, “DNS Security Introduction and Requirements”, IETF RFC 4033, Mar. We have pointed out several vulnerabilities in TOTD and 2005. DOI: 10.17487/rfc4033 mtd64ng. As they do not currently support caching, thus, cache [11]J. Linkova, “Let’s talk about IPv6 DNS64 & DNSSEC”, APNIC poisoning is not possible in their cases. As the implementation Blog, 2016, https://blog.apnic.net/2016/06/09/letstalkipv6 of caching is included in the midterm development plans of dns64dnssec/ mtd64ng, we have also given recommendations for the [12]C. Bao, C. Huitema, M. Bagnulo, M Boucadair and X. Li, “IPv6 elimination of its uncovered vulnerabilities. addressing of IPv4/IPv6 translators”, IETF RFC 6052, Oct. 2010. DOI: 10.17487/rfc6052 As for BIND, PowerDNS, and Unbound, we have not found [13]A. Hubert, R. van Mook, “Measures for making DNS more any vulnerabilities that could lead to cache poisoning. resilient against forged answers”, IETF RFC 5452, Jan. 2009. DOI: 10.17487/rfc5452 REFERENCES [14]M. Larsen, F. Gont, “Recommendations for transportprotocol port randomization”, IETF RFC 6056, Jan. 2011. DOI: [1] E. Nordmark, R. Gilligan, “Basic transition mechanisms for IPv6 10.17487/rfc6056 hosts and routers”, IETF RFC 4213, October 2005. DOI: 10.17487/rfc4213 12 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < 12 13 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < Table 3. Summary of the Vulnerability Test Results > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
Table 3. Summary of the VulnerabilityAttack Test Type Results [15]CERT, “Various DNS service implementations generate multiple [35]G. Lencse, “dns64perf source code”, DNS64 Implementation Transaction ID Prediction Source Port Number Prediction Multiple Equivalent Queries DNS Cache Poisoning simultaneous queries for the same resource record”, Vulnerability http://ipv6.tilb.sze.hu/dns64perf/ Attack Type Note VU#457875, [Online]. Available: [36]R. Jain, “Testing random number generators”, Washington DNS64BIND 9.9.5 Implementation no problem found no problem found protected no problem found Transaction ID Prediction Source Port Number Prediction Multiple Equivalent Queries DNS Cache Poisoning https://www.kb.cert.org/vuls/id/457875 University, Saint Louis, lecture notes, 2008, [Online]. Available: TOTD 1.5.2 vulnerable vulnerable vulnerable not applicable BIND 9.9.5 no problem found no problem found protected no problem found [16]D. J. Bernstein, “DNS forgery”, [Online]. Available: https://www.cse.wustl.edu/~jain/cse56708/ftp/k_27trg.pdf TOTD 1.5.3 protected vulnerable vulnerable not applicable http://cr.yp.to/djbdns/forgery.html [37]I. Petrila, V. Manta, F. Ungureanu, “Uniformity and correlation TOTD 1.5.2 vulnerable vulnerable vulnerable NFOCOMMUNICATIONSnot applicable OURNAL [17] CERT, “Multiple DNS implementations vulnerable to cache test parameters for random numbers generators”, mtd64ng 1.1.0 vulnerable vulnerable vulnerable I not applicableJ MethodologyTOTD 1.5.3 for DNS Cache Poisoningprotected Vulnerability vulnerable vulnerable not applicable poisoning”, Vulnerability Note VU#800113 [Online]. Available: PowerDNS 3.6.2 no problem found no problem found protected no problem found Analysismtd64ng12 1.1.0of DNS64 Implementationsvulnerable vulnerable vulnerable not applicable http://www.kb.cert.org/vuls/id/800113 , Sinaia, Romania, Oct. 17–19, 2014, DOI: Unbound 1.6.0 no problem found no problem found protected no problem found [18]S. Friendl, “An Illustrated Guide to the Kaminsky DNS 10.1109/ICSTCC.2014.6982421 PowerDNS> REPLACE 3.6.2 THIS LINE WITHno problem YOUR found PAPER IDENTIFICATIONno problem found NUMBER (DOUBLECLICKprotected HEREno TOproblem EDIT) found < Vulnerability”, , [Online]. Available: [38]D. Bakai, “mtd64ng: A lightweight multithreaded C++11 Unbound 1.6.0 no problem found no problem found protected no problem found http://unixwiz.net/techtips/iguidekaminskydnsvuln.html DNS64 server”, [Online]. Available: eliminate the possibility of sending out multipleTable 3. Summary equivalent of the Vulnerability[2] G. Lencse, Test Results Y. Kadobayashi, “Survey of IPv6 transition [19]DNSOARC, “Test my DNS”, web based Transaction ID and https://github.com/bakaid/mtd64ng/ queries concurrently. technologies for security analysis”, IEICE Technical Committee source port randomness tester, [Online]. Available: [39]G. Lencse, “birthdaytest source code”, [2] G. Lencse, Y. Kadobayashi, “Survey of IPv6 transition eliminate We note the that possibility all the examined of sending DNS64 out implementations multiple equivalent are onAttack Internet Type Architecture (IA) Workshop, Tokyo Japan, Aug. 28, https://www.dnsoarc.net/oarc/services/dnsentropy http://ipv6.tilb.sze.hu/DNSbirthdaytest/ DNS64 Implementation technologies2017, for security vol.analysis”, 117, no. IEICE 187, pp.Technica 19–24.l Committee [20]InfosecEvents, “More DNS cache poisoning testing tools”, [40]M. Welschenbach, “Large Random Numbers”, In: queriesfree software concurrently. [25] (also calledTransaction open ID source Prediction [26]), Source thus Port their Number Prediction Multiple Equivalent Queries DNS Cache Poisoning We note that all the examined DNS64 implementations are [3] onM. Internet Georgescu, Architecture H. Hazeyama, (IA) Workshop, T. Okuda, Y.Tokyo Kadobayashi Japan, Aug., and 28, S. [Online]. Available: http://infosecevents.net/2008/07/24/more 2nd Ed, Apress, Berkeley, CA, 2013. DOI: sourceBIND code9.9.5 may also be studied,no problem as we found did it in the caseno problem of found2017, protected vol. 117, no. 187, nopp. problem 19–24. found free software [25] (also called open source [26]), thus their Yamaguchi, “The STRIDE towards IPv6: A comprehensive dnscachepoisoningtestingtools/ 10.1007/9781430250999_12 TOTDTOTD [30].1.5.2 The significance of vulnerableour testing method is thatvulnerable it [3] M.threat Georgescu, model H. forvulnerable Hazeyama, IPv6 transition T. Okuda, technologies”, Y. notKadobayashi applicable , and S. [21]Kim, Davies, “DNS cache poisoning vulnerability: Explanation source code may also be studied, as we did it in the case of Yamaguchi, “The STRIDE towards IPv6: A comprehensive mayTOTD also 1.5.3 be used for closed sourceprotected software, or in the casesvulnerable vulnerable not applicable and remedies”, ICANN presentation, Viareggio, Italy, Oct. 2008, TOTDwhen the [30]. subject The ofsignificance the study alsoof our includes testing the method interaction is that with it threat model, Rome, for Feb. IPv6 2016. transition DOI: 10.13140/RG.2.1.2781.6085 technologies”, [Online]. Available: received his MSc and mtd64ng 1.1.0 vulnerable vulnerable vulnerable not applicable maythe random also be number used for generator closed sourceof the operatingsoftware, systemor in the. cases [4] M. Bagnulo, A Sullivan, P. Matthews and I. Beijnum, “DNS64: https://www.iana.org/about/presentations/daviesviareggio PhD in computer science from the whenPowerDNS the subject 3.6.2 of the study alsono problem includes found the interactionno with problem found DNS extensions, Rome, Feb. forprotected network 2016. DOI: address 10.13140/RG.2.1.2781.6085 translationno problem from foundIPv6 clients entropyvuln081002.pdf The very same framework could be used for the analysis of [4] M. Bagnulo, A Sullivan, P. Matthews and I. Beijnum, “DNS64: Budapest University of Technology and theUnbound random 1.6.0 number generator ofno the problem operating found system. no problem found to IPv4 servers”, RFCprotected 6147, Apr. 2011. DOI:no problem 10.1748 found7/rfc6147 [22]G. Lencse, S. Répás, “Benchmarking further single board NAT64 gateways. DNS extensions for network address translation from IPv6 clients Economics, Budapest, Hungary in 1994 The very same framework could be used for the analysis of [5] M. Bagnulo, P. Matthews and I. Beijnum, “Stateful NAT64: computers for building a mini supercomputer for simulation of toNetwork IPv4 servers”, address RFC and 6147, protocol Apr. translation 2011. DOI: from 10.1748 IPv67/rfc6147 clients to telecommunication systems”, and 2001, respectively. NAT64 gateways. eliminate the possibilityX. of C sendingONCLUSION out multiple equivalent [5][2] M.IPv4G. Bagnulo, Lencse, servers”, P.Y. Matthews Kadobayashi, IETF RFC and I. “Survey 6146, Beijnum, Apr. of “Stateful IPv6 2011. transiti NAT64: DOI:on , He has been working full time for the Network10.17487/rfc6146 address and protocol translation from IPv6 clients to vol. 5. no. 1, 2016, pp. 29–36, DOI: 10.11601/ijates.v5i1.138 Department of Telecommunications, queriesWe have concurrently. shown that DNS cache poisoning may be a crucial technologies for security analysis”, IEICE Technical Committee X. CONCLUSION [6] IPv4G.on Lencse,Internet servers”, Y.Architecture Kadobayashi, IETF (IA) RFC “Methodology Workshop, 6146, Tokyo Apr.for the Japan 2011.identification, Aug. DOI: 28, [23]D. Bakai, “DebianVM”, [Online]. Available: Széchenyi István University, Győr, vulnerabilityWe note that of all DNS64 the examined servers DNS64 and weimplementations have given are an 10.17487/rfc6146 We have shown that DNS cache poisoning may be a crucial of2017, potential security vol. issues 117, ofno. 187, different pp. 19–24. IPv6 transition https://git.sch.bme.hu/bakaid/debianvm Hungary since 1997. Now, he is an introductionfree software to [25] the (also three called main open components source [26]), of DNS thus ca theirche [6] G.technologies: Lencse, Y. Kadobayashi, Threat analysis “Methodology of DNS64 and for statefulthe identification NAT64”, [24]Internet Systems Consortium, “BIND: Versatile, Classic, vulnerability of DNS64 servers and we have given an [3] M. Georgescu, H. Hazeyama, T. Okuda, Y. Kadobayashi, and S. Associate Professor. He has been working part time for the poisoningsource code vulnerability, may also be namelystudied, Transactionas we did it IDin th prede caseiction, of ofYamaguchi, potential “The security STRIDE , vol.issues 77, towards of no. different 1, IPv6: pp. 397411, A IPv6 comprehensiv Augusttransition 1,e Complete Name Server Software”, [Online]. Available: Department of Networked Systems and Services, Budapest introductionsourceTOTD port[30]. number toThe the significance prediction, three main of and componentsour a testingbirthday method of parad DNS oxis that cabasedche it technologies:2018,threat DOI: model 10.1016/j.cose.2018.04.012 Threat for IPv6 analysis transition of DNS64 technologies”, and stateful NAT64”, https://www.isc.org/downloads/bind , vol. 77, no. 1, pp. 397411, August 1, University of Technology and Economics, Budapest, Hungary poisoningattack,may also which be vulnerability, usedis possible for closed if namely a DNSsource Transactionor software,DNS64 server IDor in pred sendstheiction, cases out [7] S. Son and V. Shmatikov, “The hitchhiker’s guide to DNS cache [25]Free Software Foundation, “The free software definition”, 2018,poisoning”, DOI: 10.1016/j.cose.2018.04.012 in [Online]. Available: http://www.gnu.org/philosophy/free as a Senior Research Fellow since 2005. At the time of writing sourcemultiplewhen the port equivalent subject number of queriestheprediction, study concurrently. also and includes a birthday the intparaderactionox based with , Rome, Feb. 2016. DOI: 10.13140/RG.2.1.2781.6085 attack, which is possible if a DNS or DNS64 server sends out [7][4] S.M. Son Bagnulo, and V. AShmatikov, Sullivan, P.“The Matthews hitchhiker’s and I. guide Beijnum, to DNS “DNS64: cache sw.en.html this paper he was a Guest Researcher at the Laboratory for theAfter random surveying number generator the available of the test operating tools forsystem DNS. cache poisoning”, in multiple equivalent queries concurrently. DNS extensions, Singapore, for network Sep. 7–9,address 2010, translation pp. from 466–483, IPv6 clients DOI: [26]Open Source Initiative, “The open source definition”, [Online]. Cyber Resilience, Nara Institute of Science and Technology, poisoningThe very vulnerability same framework analysis could and be pointing used for out the that analy theysis are of 10.1007/9783642161612_27 Available: http://opensource.org/docs/osd After surveying the available test tools for DNS cache to IPv4 servers”, RFC 6147, Apr. 2011. DOI: 10.17487/rfc6147 Japan, where his research area was the security analysis of IPv6 notNAT64 suitable gateways. for our purposes, we have designed a methodology [8][5] G.M. Lencse Bagnulo,, Singapore, and P.Y. MatthewsKadobayashi, Sep. 7–9, and “Testbed I. 2010, Beijnum, for pp. security “Stateful 466–483, analysis NAT64: DOI: of [27]Cisco, “End user license agreement”, [Online]. Available: transition technologies. poisoningand implemented vulnerability it in analysis a testbed, and which pointing can out be that used they for are the 10.1007/9783642161612_27theNetwork DNS64 address IPv6 transition and protocol technology translation in virtual from IPv6environment”, clients to http://www.cisco.com/c/en/us/products/enduserlicense [8] G. Lencse and Y. Kadobayashi, “Testbed for security analysis of Dr. Lencse is a member of IEICE (Institute of Electronics, notsystematic suitable testing for our of purposes, DNSX. or C DNS64weONCLUSION have implementations, designed a methodology whether IEICEIPv4 Communications servers”, IETF Society RFC Internet 6146, Architecture Apr. 2011. Workshop, DOI: agreement.html and implemented it in a testbed, which can be used for the theTokyo,10.17487/rfc6146 DNS64 Japan, IPv6 Oct. transition 13, 2017, technology in virtual, vol. env 117,ironment”, no. 239, [28]Juniper Networks, “End user license agreement”, [Online]. Information and Communication Engineers, Japan). theyWe have are shown susceptible that DNS to cache the poisoning above mentioned may be a crucial three systematic testing of DNS or DNS64 implementations, whether [6] IEICEpp.G. Lencse, 1924. Communications Y. Kadobayashi, Society “Methodology Internet Architecture for the ide Workshop,ntification Available: http://www.juniper.net/support/eula/ vulnerabilities.vulnerability of DNS64 servers and we have given an [9] Tokyo,G. Lencse Japan, andOct. 13, Y. 2017, Kadobayashi, “Benchmarking, vol. 117, no. DNS64 239, they are susceptible to the above mentioned three of potential security issues of different IPv6 transition [29]The 6NET Consortium, Ed. M. Dunmore, “An IPv6 Deployment introductionWe have selected to the BIND, three mainPowerDNS, components Unbound of two DNS versions cache pp.Implementations: 1924. Theory and Practice”, Guide”, Sep. 2005. [Online]. Available: vulnerabilities. technologies: Threat analysis of DNS64 and stateful NAT64”, received his poisoningof TOTD, vulnerability,and mtd64ng namely for testing Transaction and also presented ID prediction, their [9] G. Lencse and , vol. Y. 127,, Kadobayashi, vol. no. 77, 1, no.pp. 1,6174, “Benchmarking pp. 397411,September August 1, DNS64 2018, 1, http://www.6net.org/book/deploymentguide.pdf 12 We have selected BIND, PowerDNS, Unbound two versions Implementations: Theory and Practice”, Ph.D. degree in computer science from sourcesetup. Weport have number carried prediction, out their and testing a birthday concerning parad oxthe basedthree DOI:2018, 10.1016/j.comcom.2018.05.005DOI: 10.1016/j.cose.2018.04.012 [30]G. Lencse and S. Répás, “Improving the performance and security > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATIONof TOTD, NUMBER and mtd64ng (DOUBLECLICK for testing HERE and also TO presented EDIT) < their [10]R. Arends, R. Austein,, vol. 127, M. no.Larson, 1, pp. D. 6174, Massey, September S. Ros e,1, “DNS2018, of the TOTD DNS64 implementation”, Osaka University, Japan, in 1997. possibleattack, which components is possible of the if DNSa DNS cache or DNS64 poisoning server vuln sendserability. out [7] S. Son and V. Shmatikov, “The hitchhiker’s guide to DNS cache setup. We have carried out their testing concerning the three DOI:poisoning”,Security 10.1016/j.comcom.2018.05.005 Introduction in and Requirements”, IETF RFC 4033, Mar. (, Argentina), vol. 14, no. 1, Apr. He is currently a Professor in the Wemultiple have equivalent pointed outqueries several concurrently. vulnerabilities in TOTD and [10]R.2005. Arends, DOI: R.10.17487/rfc4033 Austein, M. Larson, D. Massey, S. Rose, “DNS 2014, ISSN: 16666038, pp. 9–15. Table 3. Summary of the Vulnerabilitypossible components Test Results of the DNS cache poisoning vulnerability. Graduate School of Information mtd64ng.After surveying As they do the not availablecurrently support test tools caching, for DNS thus, cacacheche [11] SecurityJ. Linkova, Introduction “Let’s talk and about Requirements”, IPv6 DNS64 IETF & DNSSEC”, RFC 4033, APNIC Mar. We have pointed out several vulnerabilities in TOTD and , Singapore, Sep. 7–9, 2010, pp. 466–483, DOI: http://journal.info.unlp.edu.ar/journal/ Science, Nara Institute of Science and poisoning isvulnerability not possible analysis in their andcases. pointing As the out implementation that they are 2005.Blog, DOI: 2016, 10.17487/rfc4033 https://blog.apnic.net/2016/06/09/lets talkipv6 [31]G. Lencse and D. Bakai, “Design, implementation and mtd64ng.Attack As Type they do not currently support caching, thus, cache 10.1007/9783642161612_27 Technology, Japan. Since 2013, he has DNS64 Implementation notof cachingsuitable isfor included our purposes, in the we midterm have designed development a methodology plans of [11][8]J.G.dns64dnssec/ Linkova, Lencse and“Let’s Y. Kadobayashi,talk about IPv6 “Testbed DNS64 for& DNSSEC”,security analysis APNIC of performance estimation of mtd64ng a new tiny DNS64 proxy”, Transaction ID Prediction Source Port Numberpoisoning Prediction is not Multiple possible Equivalent in their Queries cases. As DNS the Cache implementation Poisoning Blog, 2016, https://blog.apnic.net/2016/06/09/letstalkipv6 also been working as the Rapporteur of andmtd64ng, implemented we have it in also a testbed, given which recommendations can be used forfor ththee [12]theC. Bao, DNS64 C. Huitema, IPv6 transition M. Bagnulo, technology M Boucadair in virtual and env X.ironment”, Li, “IPv6 , vol. 25, no. BIND 9.9.5 no problem found no problem foundof caching is includedprotec inted the midterm developmentno problem found plans of dns64dnssec/addressing of IPv4/IPv6 translators”, IETF RFC 6052, Oct. 2010. 2, Jun. 2017, pp. 91–102, DOI:10.20532/cit.2017.1003419 ITUT Q.4/17 for cybersecurity systematicelimination testing of its uncovered of DNS or vulnerabilities.DNS64 implementations, whether IEICE Communications Society Internet Architecture Workshop, mtd64ng, we have also given recommendations for the [12]C.Tokyo,DOI: Bao, 10.17487/rfc6052 Japan,C. Huitema, Oct. 13, M. 2017, Bagnulo, M Boucadair, vol.and 117,X. Li, no. “IPv6 239, [32]Powerdns.com BV, “PowerDNS”, [Online]. Available: standardization. His research interests include cybersecurity, TOTD 1.5.2 vulnerable vulnerablethey As for are BIND, susceptible PowerDNS,vulnerable to and the Unbound, above notwe mentioned app havelicable not fou threend elimination of its uncovered vulnerabilities. [13]addressingpp.A. Hubert,1924. of R. IPv4/IPv6 van Mook, translators”, “Measures IETF for RFC making 6052 , DNSOct. 2010. more http://www.powerdns.com web security, and distributed systems. TOTD 1.5.3 protected vulnerablevulnerabilities.any vulnerabilities thatvulnerable could lead to cache poisonnot appling.icable DOI:resilient 10.17487/rfc6052 against forged answers”, IETF RFC 5452, Jan. 2009. As for BIND, PowerDNS, and Unbound, we have not found [9] G. Lencse and Y. Kadobayashi, “Benchmarking DNS64 [33]NLnet Labs, “Unbound”, [Online]. Available: http://unbound.net Dr. Kadobayashi is a member of IEEE Communications mtd64ng 1.1.0 vulnerable vulnerable We have selectedvulnerable BIND, PowerDNS, Unboundnot applicable two versions [13]A.Implementations:DOI: Hubert, 10.17487/rfc5452 R. van Mook, Theory “Measures and for Practice”, making DNS more [34]G. Lencse, “Test program for the performance analysis of DNS64 any vulnerabilities that could lead to cache poisoning. resilient against forged answers”, IETF RFC 5452, Jan. 2009. society. PowerDNS 3.6.2 no problem found no problem foundof TOTD, and mtd64ngprotectedR forEFERENCES testing and no also problem presented found their [14]M. Larsen, F. Gont,, vol. “Recommendations127, no. 1, pp. 6174, for September transport protocol1, 2018, servers”, DOI:port 10.17487/rfc5452 randomization”, IETF RFC 6056, Jan. 2011. DOI: , vol. Unbound 1.6.0 no problem found no problem foundsetup.[1] E. WeNordmark, have carriedR. Gilligan,protected out “Basictheir testingtransition concerningno mechani problemsms found the for three IPv6 13DOI: 10.1016/j.comcom.2018.05.005 REFERENCES [14]M.10.17487/rfc6056 Larsen, F. Gont, “Recommendations for transportprotocol 4, no. 3, 2015, pp 60–65. DOI: 10.11601/ijates.v4i3.121 possiblehosts components and routers”, of the IETF DNS RFC cache 4213, poisoning October vuln 2005.erability. DOI: [10]> REPLACER. Arends, R. THIS Austein, LINE M. WITH Larson, YOUR D. Massey, PAPER S. RosIDENTIFICATIONe, “DNS NUMBER (DOUBLECLICK HERE TO EDIT) < portSecurity randomization”, Introduction and IETF Requirements”, RFC 6056, IETF Jan. RFC 2011. 4033, DOI:Mar. [1]We E.10.17487/rfc4213 have Nordmark, pointed R. Gilligan, out several “Basic vulnerabilities transition mechani in sms TOTD for IPv6 and 10.17487/rfc6056 eliminate the possibility of sending out multiple equivalent [2] hostsG. Lencse, and routers”, Y. Kadobayashi, IETF RFC “Survey 4213, October of IPv6 2005. transiti DOonI: 2005. DOI: 10.17487/rfc4033 mtd64ng. As they do not currently support caching, thus, cache [15][11]CERT,J. Linkova, “Various “Let’s DNS talk service about IPv6 implementations DNS64 & DNSSEC”, generate multiple APNIC [35]G. Lencse, “dns64perf source code”, queries concurrently. 10.17487/rfc4213technologies for security analysis”, IEICE Technical Committee poisoning is not possible in their cases. As the implementation simultaneousBlog, 2016, queries https://blog.apnic.net/2016/06/09/lets for the same resource record”, Vulnerabilitytalkipv6 http://ipv6.tilb.sze.hu/dns64perf/ We note that all the examined DNS64 implementations are on Internet Architecture (IA) Workshop, Tokyo Japan, Aug. 28, Note VU#457875, [Online]. Available: [36]R. Jain, “Testing random number generators”, Washington of caching2017, is included in vol. the 117, midterm no. 187, development pp. 19–24. plans of dns64dnssec/ free software [25] (also called open source [26]), thus their [12]https://www.kb.cert.org/vuls/id/457875C. Bao, C. Huitema, M. Bagnulo, M Boucadair and X. Li, “IPv6 University, Saint Louis, lecture notes, 2008, [Online]. Available: mtd64ng,[3] M. Georgescu, we have H. Hazeyama, also given T. Okuda, recommendations Y. Kadobayashi for, and th S.e [16]D. J. Bernstein, “DNS forgery”, [Online]. Available: https://www.cse.wustl.edu/~jain/cse56708/ftp/k_27trg.pdf source code may also be studied, as we did it in the case of eliminationYamaguchi, of its “The uncovered STRIDE vulnerabilities. towards IPv6: A comprehensive addressing of IPv4/IPv6 translators”, IETF RFC 6052, Oct. 2010. TOTD [30]. The significance of our testing method is that it http://cr.yp.to/djbdns/forgery.htmlDOI: 10.17487/rfc6052 [37]I. Petrila, V. Manta, F. Ungureanu, “Uniformity and correlation Asthreat for BIND, model PowerDNS, for IPv6 transition and Unbound, technologies”, we have not fou nd [17]CERT, “Multiple DNS implementations vulnerable to cache test parameters for random numbers generators”, may also be used for closed source software, or in the cases [13]A. Hubert, R. van Mook, “Measures for making DNS more any vulnerabilities that could lead to cache poisoning. poisoning”,resilient against Vulnerability forged answers”, Note VU#800113 IETF RFC [Online]. 5452, Available: Jan. 2009. when the subject of the study also includes the interaction with , Rome, Feb. 2016. DOI: 10.13140/RG.2.1.2781.6085 http://www.kb.cert.org/vuls/id/800113DOI: 10.17487/rfc5452 , Sinaia, Romania, Oct. 17–19, 2014, DOI: the random number generator of the operating system. [4] M. Bagnulo, A Sullivan, P. Matthews and I. Beijnum, “DNS64: [18]S. Friendl, “An Illustrated Guide to the Kaminsky DNS 10.1109/ICSTCC.2014.6982421 REFERENCES [14]M. Larsen, F. Gont, “Recommendations for transportprotocol DNS extensions for network address translation from IPv6 clients Vulnerability”, , [Online]. Available: [38]D. Bakai, “mtd64ng: A lightweight multithreaded C++11 The very same framework could be used for the analysis of to IPv4 servers”, RFC 6147, Apr. 2011. DOI: 10.17487/rfc6147 port randomization”, IETF RFC 6056, Jan. 2011. DOI: NAT64 gateways. [1] E. Nordmark, R. Gilligan, “Basic transition mechanisms for IPv6 http://unixwiz.net/techtips/iguidekaminskydnsvul10.17487/rfc6056 n.html DNS64 server”, [Online]. Available: [5] hostsM. Bagnulo, and routers”, P. Matthews IETF and RFC I. 4213, Beijnum, October “Stateful 2005. NAT64: DOI: [19]DNSOARC, “Test my DNS”, web based Transaction ID and https://github.com/bakaid/mtd64ng/ 10.17487/rfc4213Network address and protocol translation from IPv6 clients to source port randomness tester, [Online]. Available: [39]G. Lencse, “birthdaytest source code”, X. CONCLUSION IPv4 servers”, IETF RFC 6146, Apr. 2011. DOI: https://www.dnsoarc.net/oarc/services/dnsentropy http://ipv6.tilb.sze.hu/DNSbirthdaytest/ 10.17487/rfc6146 [20]InfosecEvents, “More DNS cache poisoning testing tools”, [40]M. Welschenbach, “Large Random Numbers”, In: We have shown that DNS cache poisoning may be a crucial [6] G. Lencse, Y. Kadobayashi, “Methodology for the identification vulnerability of DNS64 servers and we have given an [Online]. Available: http://infosecevents.net/2008/07/24/more 2nd Ed, Apress, Berkeley, CA, 2013. DOI: of potential security issues of different IPv6 transition dnscachepoisoningtestingtools/ 10.1007/9781430250999_12 introduction to the three main components of DNS cache technologies: Threat analysis of DNS64 and stateful NAT64”, [21]Kim, Davies, “DNS cache poisoning vulnerability: Explanation JUNE 2018 VOLUME X NUMBER 2 poisoning vulnerability, namely Transaction ID prediction, 24 , vol. 77, no. 1, pp. 397411, August 1, and remedies”, ICANN presentation, Viareggio,• Italy,• Oct. 2008, source port number prediction, and a birthday paradox based 2018, DOI: 10.1016/j.cose.2018.04.012 [Online]. Available: received his MSc and [7] S. Son and V. Shmatikov, “The hitchhiker’s guide to DNS cache attack, which is possible if a DNS or DNS64 server sends out https://www.iana.org/about/presentations/daviesviareggio PhD in computer science from the poisoning”, in entropyvuln081002.pdf multiple equivalent queries concurrently. Budapest University of Technology and After surveying the available test tools for DNS cache [22]G. Lencse, S. Répás, “Benchmarking further single board , Singapore, Sep. 7–9, 2010, pp. 466–483, DOI: computers for building a mini supercomputer for simulation of Economics, Budapest, Hungary in 1994 poisoning vulnerability analysis and pointing out that they are 10.1007/9783642161612_27 telecommunication systems”, and 2001, respectively. not suitable for our purposes, we have designed a methodology [8] G. Lencse and Y. Kadobayashi, “Testbed for security analysis of , He has been working full time for the and implemented it in a testbed, which can be used for the the DNS64 IPv6 transition technology in virtual environment”, vol. 5. no. 1, 2016, pp. 29–36, DOI: 10.11601/ijates.v5i1.138 Department of Telecommunications, IEICE Communications Society Internet Architecture Workshop, systematic testing of DNS or DNS64 implementations, whether [23]D. Bakai, “DebianVM”, [Online]. Available: Széchenyi István University, Győr, Tokyo, Japan, Oct. 13, 2017, , vol. 117, no. 239, https://git.sch.bme.hu/bakaid/debianvm they are susceptible to the above mentioned three pp. 1924. Hungary since 1997. Now, he is an vulnerabilities. [24]Internet Systems Consortium, “BIND: Versatile, Classic, [9] G. Lencse and Y. Kadobayashi, “Benchmarking DNS64 Complete Name Server Software”, [Online]. Available: Associate Professor. He has been working part time for the We have selected BIND, PowerDNS, Unbound two versions Implementations: Theory and Practice”, https://www.isc.org/downloads/bind Department of Networked Systems and Services, Budapest of TOTD, and mtd64ng for testing and also presented their , vol. 127, no. 1, pp. 6174, September 1, 2018, [25]Free Software Foundation, “The free software definition”, University of Technology and Economics, Budapest, Hungary setup. We have carried out their testing concerning the three DOI: 10.1016/j.comcom.2018.05.005 [Online]. Available: http://www.gnu.org/philosophy/free as a Senior Research Fellow since 2005. At the time of writing [10]R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, “DNS possible components of the DNS cache poisoning vulnerability. sw.en.html this paper he was a Guest Researcher at the Laboratory for Security Introduction and Requirements”, IETF RFC 4033, Mar. [26]Open Source Initiative, “The open source definition”, [Online]. We have pointed out several vulnerabilities in TOTD and 2005. DOI: 10.17487/rfc4033 Cyber Resilience, Nara Institute of Science and Technology, mtd64ng. As they do not currently support caching, thus, cache Available: http://opensource.org/docs/osd [11]J. Linkova, “Let’s talk about IPv6 DNS64 & DNSSEC”, APNIC [27]Cisco, “End user license agreement”, [Online]. Available: Japan, where his research area was the security analysis of IPv6 poisoning is not possible in their cases. As the implementation Blog, 2016, https://blog.apnic.net/2016/06/09/letstalkipv6 http://www.cisco.com/c/en/us/products/enduserlicense transition technologies. of caching is included in the midterm development plans of dns64dnssec/ agreement.html Dr. Lencse is a member of IEICE (Institute of Electronics, mtd64ng, we have also given recommendations for the [12]C. Bao, C. Huitema, M. Bagnulo, M Boucadair and X. Li, “IPv6 [28]Juniper Networks, “End user license agreement”, [Online]. Information and Communication Engineers, Japan). addressing of IPv4/IPv6 translators”, IETF RFC 6052, Oct. 2010. elimination of its uncovered vulnerabilities. Available: http://www.juniper.net/support/eula/ DOI: 10.17487/rfc6052 [29]The 6NET Consortium, Ed. M. Dunmore, “An IPv6 Deployment As for BIND, PowerDNS, and Unbound, we have not found [13]A. Hubert, R. van Mook, “Measures for making DNS more any vulnerabilities that could lead to cache poisoning. Guide”, Sep. 2005. [Online]. Available: resilient against forged answers”, IETF RFC 5452, Jan. 2009. http://www.6net.org/book/deploymentguide.pdf received his DOI: 10.17487/rfc5452 [30]G. Lencse and S. Répás, “Improving the performance and security Ph.D. degree in computer science from REFERENCES [14]M. Larsen, F. Gont, “Recommendations for transportprotocol of the TOTD DNS64 implementation”, Osaka University, Japan, in 1997. port randomization”, IETF RFC 6056, Jan. 2011. DOI: (, Argentina), vol. 14, no. 1, Apr. He is currently a Professor in the [1] E. Nordmark, R. Gilligan, “Basic transition mechanisms for IPv6 10.17487/rfc6056 hosts and routers”, IETF RFC 4213, October 2005. DOI: 2014, ISSN: 16666038, pp. 9–15. Graduate School of Information 10.17487/rfc4213 http://journal.info.unlp.edu.ar/journal/ Science, Nara Institute of Science and [31]G. Lencse and D. Bakai, “Design, implementation and performance estimation of mtd64ng a new tiny DNS64 proxy”, Technology, Japan. Since 2013, he has , vol. 25, no. also been working as the Rapporteur of 2, Jun. 2017, pp. 91–102, DOI:10.20532/cit.2017.1003419 ITUT Q.4/17 for cybersecurity [32]Powerdns.com BV, “PowerDNS”, [Online]. Available: standardization. His research interests include cybersecurity, http://www.powerdns.com web security, and distributed systems. [33]NLnet Labs, “Unbound”, [Online]. Available: http://unbound.net Dr. Kadobayashi is a member of IEEE Communications [34]G. Lencse, “Test program for the performance analysis of DNS64 servers”, society. , vol. 4, no. 3, 2015, pp 60–65. DOI: 10.11601/ijates.v4i3.121
12 13 > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) < > REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLECLICK HERE TO EDIT) <
Table 3. Summary of the Vulnerability Test Results [15]CERT, “Various DNS service implementations generate multiple [35]G. Lencse, “dns64perf source code”, simultaneous queries for the same resource record”, Vulnerability http://ipv6.tilb.sze.hu/dns64perf/ Attack Type Note VU#457875, [Online]. Available: [36]R. Jain, “Testing random number generators”, Washington DNS64 Implementation Transaction ID Prediction Source Port Number Prediction Multiple Equivalent Queries DNS Cache Poisoning https://www.kb.cert.org/vuls/id/457875 University, Saint Louis, lecture notes, 2008, [Online]. Available: BIND 9.9.5 no problem found no problem found protected no problem found [16]D. J. Bernstein, “DNS forgery”, [Online]. Available: https://www.cse.wustl.edu/~jain/cse56708/ftp/k_27trg.pdf http://cr.yp.to/djbdns/forgery.html [37]I. Petrila, V. Manta, F. Ungureanu, “Uniformity and correlation TOTD 1.5.2 vulnerable vulnerable vulnerable not applicable [17]INFOCOMMUNICATIONSCERT, “Multiple DNS JOURNAL implementations vulnerable to cache test parameters for random numbers generators”, TOTD 1.5.3 protected vulnerable vulnerable not applicable poisoning”, Vulnerability Note VU#800113 [Online]. Available: Methodology for DNS Cache Poisoning Vulnerability mtd64ng12 1.1.0 vulnerable vulnerable vulnerable not applicable 13http://www.kb.cert.org/vuls/id/800113 Analysis, Sinaia, Romania,of DNS64 Oct. Implementations 17–19, 2014, DOI: [18]S. Friendl, “An Illustrated Guide to the Kaminsky DNS 10.1109/ICSTCC.2014.6982421 PowerDNS> REPLACE 3.6.2 THIS LINE WITHno problem YOUR found PAPER IDENTIFICATIONno problem found NUMBER (DOUBLECLICKprotected HEREno TOproblem EDIT) found < > REPLACEVulnerability”, THIS LINE WITH, YOUR [Online]. PAPER IDENTIFICATION Available: [38]D. NUMBER Bakai, “mtd64ng: (DOUBLECLICK A lightweight HERE multithreaded TO EDIT) < C++11 Unbound 1.6.0 no problem found no problem found protected no problem found http://unixwiz.net/techtips/iguidekaminskydnsvuln.html DNS64 server”, [Online]. Available: Table 3. Summary of the Vulnerability Test Results [15][19]CERT,DNSOARC, “Various “Test DNS my service DNS”, implementations web based Transaction generate multiple ID and [35]G.https://github.com/bakaid/mtd64ng/ Lencse, “dns64perf source code”, simultaneoussource port queries randomness for the same tester, resource [Online].record”, Vulnerability Available: [39]http://ipv6.tilb.sze.hu/dns64perf/G. Lencse, “birthdaytest source code”, eliminate the possibility of sending out multiple equivalent [2] G.Attack Lencse, Type Y. Kadobayashi, “Survey of IPv6 transition Notehttps://www.dnsoarc.net/oarc/services/dnsentropy VU#457875, [Online]. Available: [36]R.http://ipv6.tilb.sze.hu/DNSbirthdaytest/ Jain, “Testing random number generators”, Washington DNS64 Implementation technologies for security analysis”, IEICE Technical Committee queries concurrently. Transaction ID Prediction Source Port Number Prediction Multiple Equivalent Queries DNS Cache Poisoning [20]https://www.kb.cert.org/vuls/id/457875InfosecEvents, “More DNS cache poisoning testing tools”, [40]University,M. Welschenbach, Saint Louis, “Large lecture Random notes, Numbers”, 2008, [Onli In:ne]. Available: We note that all the examined DNS64 implementations are on Internet Architecture (IA) Workshop, Tokyo Japan, Aug. 28, [16]D.[Online]. J. Bernstein, Available: “DNS http://infosecevents.net/2008/ forgery”, [Online]. 07/24/more Available: https://www.cse.wustl.edu/~jain/cse56708/ftp/k_27t 2nd Ed, Apress, Berkeley, CA, rg.pdf 2013. DOI: BIND 9.9.5 no problem found no problem found2017, protected vol. 117, no. 187, nopp. problem 19–24. found http://cr.yp.to/djbdns/forgery.html [37] I. Petrila, V. Manta, F. Ungureanu, “Uniformity and correlation free software [25] (also called open source [26]), thus their dnscachepoisoningtestingtools/ 10.1007/9781430250999_12 TOTD 1.5.2 vulnerable vulnerable[3] M. Georgescu, H.vulnerable Hazeyama, T. Okuda, Y. notKadobayashi applicable , and S. [17][21]CERT,Kim, Davies, “Multiple “DNS DNS cache implementations poisoning vulnerability: vulnerable Ex toplanation cache test parameters for random numbers generators”, source code may also be studied, as we did it in the case of Yamaguchi, “The STRIDE towards IPv6: A comprehensive TOTD 1.5.3 protected vulnerable vulnerable not applicable poisoning”,and remedies”, Vulnerability ICANN presentation, Note VU#800113 Viareggio, [Online]. Italy, Available:Oct. 2008, TOTD [30]. The significance of our testing method is that it threat model for IPv6 transition technologies”, http://www.kb.cert.org/vuls/id/800113[Online]. Available: , Sinaia, Romania,received Oct. 17–19, his 2014, MSc DOI: and mtd64ng 1.1.0 vulnerable vulnerable vulnerable not applicable may also be used for closed source software, or in the cases [18]S.https://www.iana.org/about/presentations/daviesvia Friendl, “An Illustrated Guide to the Kaminskyreggio DNS 10.1109/ICSTCC.2014.6982421PhD in computer science from the whenPowerDNS the subject 3.6.2 of the study alsono problem includes found the interactionno with problem found , Rome, Feb.protected 2016. DOI: 10.13140/RG.2.1.2781.6085no problem found Vulnerability”,entropyvuln081002.pdf , [Online]. Available: [38]D. Bakai, “mtd64ng: A lightweight multithreaded C++11 [4] M. Bagnulo, A Sullivan, P. Matthews and I. Beijnum, “DNS64: Budapest University of Technology and theUnbound random 1.6.0 number generator ofno the problem operating found system. no problem found protected no problem found [22]http://unixwiz.net/techtips/iguidekaminskydnsvulG. Lencse, S. Répás, “Benchmarking further n.html single board DNS64 server”, [Online]. Available: DNS extensions for network address translation from IPv6 clients [19] DNSOARC, “Test my DNS”, web based Transaction ID and https://github.com/bakaid/mtd64ng/Economics, Budapest, Hungary in 1994 The very same framework could be used for the analysis of computers for building a mini supercomputer for simulation of to IPv4 servers”, RFC 6147, Apr. 2011. DOI: 10.17487/rfc6147 sourcetelecommunication port randomness systems”, tester, [Online]. Available: [39]G. Lencse, and 2001, “birthdaytest respectively. source code”, NAT64 gateways. eliminate the possibility of sending out multiple equivalent [5][2] M.G. Bagnulo, Lencse, P.Y. Matthews Kadobayashi, and I. “Survey Beijnum, of “Stateful IPv6 transiti NAT64:on https://www.dnsoarc.net/oarc/services/dnsentropy , http://ipv6.tilb.sze.hu/DNSbirthdaytest/He has been working full time for the Network address and protocol translation from IPv6 clients to [20] InfosecEvents, “More DNS cache poisoning testing tools”, [40] M. Welschenbach, “Large Random Numbers”, In: queries concurrently. technologies for security analysis”, IEICE Technical Committee vol. 5. no. 1, 2016, pp. 29–36, DOI: 10.11601/ijates.v5i1.138 Department of Telecommunications, X. CONCLUSION IPv4on Internet servers”, Architecture IETF (IA) RFC Workshop, 6146, Tokyo Apr. Japan 2011., Aug. DOI: 28, [23][Online].D. Bakai, Available: “DebianVM”, http://infosecevents.net/2008/ [Online]. 07/24/more Available: 2ndSzéchenyi Ed, Apress, István Berkeley, University, CA, 2013. Győr, DOI: We note that all the examined DNS64 implementations are 10.17487/rfc6146 dnscachepoisoningtestingtools/ 10.1007/9781430250999_12 We have shown that DNS cache poisoning may be a crucial 2017, vol. 117, no. 187, pp. 19–24. https://git.sch.bme.hu/bakaid/debianvm Hungary since 1997. Now, he is an free software [25] (also called open source [26]), thus their [6] G. Lencse, Y. Kadobayashi, “Methodology for the identification [21][24]Kim,Internet Davies, Systems “DNS Consortium,cache poisoning “BIND: vulnerability: Versatile, Ex planation Classic, vulnerability of DNS64 servers and we have given an [3] M. Georgescu, H. Hazeyama, T. Okuda, Y. Kadobayashi, and S. Associate Professor. He has been working part time for the source code may also be studied, as we did it in the case of ofYamaguchi, potential “The security STRIDE issues towards of different IPv6: A IPv6 comprehensiv transitione andComplete remedies”, Name ICANN Server presentation, Software”, Viareggio, [Online]. Italy , Oct. Available 2008,: introductionTOTD [30]. toThe the significance three main of componentsour testing method of DNS is that cache it technologies:threat model Threat for IPv6 analysis transition of DNS64 technologies”, and stateful NAT64”, [Online].https://www.isc.org/downloads/bind Available: Department of Networked Systems andreceived Services, his MSc Budap andest poisoningmay also be vulnerability, used for closed namely source Transaction software, IDor in pred theiction, cases , vol. 77, no. 1, pp. 397411, August 1, [25]https://www.iana.org/about/presentations/daviesviaFree Software Foundation, “The free software reggio definition”, University of TechnologyGáborPhD Lencse and in computerEconomics, received his scienceBudapest, MSc and from Hungary PhD thein source port number prediction, and a birthday paradox based 2018, DOI:, Rome, 10.1016/j.cose.2018.04.012 Feb. 2016. DOI: 10.13140/RG.2.1.2781.6085 entropyvuln081002.pdf[Online]. Available: http://www.gnu.org/philosophy/free as a Senior Researchcomputer Fellow science since from 2005. the At Budapest the time University of writing of when the subject of the study also includes the interaction with TechnologyBudapest and University Economics, of Budapest, Technology Hungary and in attack, which is possible if a DNS or DNS64 server sends out [7][4] S.M. Son Bagnulo, and V. AShmatikov, Sullivan, P.“The Matthews hitchhiker’s and I. guide Beijnum, to DNS “DNS64: cache [22]G.sw.en.html Lencse, S. Répás, “Benchmarking further single board this paper he was a Guest Researcher at the Laboratory for the random number generator of the operating system. poisoning”, in computers for building a mini supercomputer for simulation of 1994Economics, and 2001, respectively. Budapest, Hungary in 1994 multiple equivalent queries concurrently. DNS extensions for network address translation from IPv6 clients [26]Open Source Initiative, “The open source definition”, [Online]. Cyber Resilience, Nara Institute of Science and Technology, The very same framework could be used for the analysis of telecommunicationAvailable: http://opensource.org/docs/osd systems”, Heand has 2001,been working respectively. full time for the Department of After surveying the available test tools for DNS cache to IPv4 servers”, RFC 6147, Apr. 2011. DOI: 10.17487/rfc6147 Japan, where his researchTelecommunications, area was the Széchenyi security anaIstvánlysis University, of IPv6 NAT64 gateways. [5] M. Bagnulo,, Singapore, P. Matthews Sep. 7–9, and I. 2010, Beijnum, pp. “Stateful 466–483, NAT64: DOI: [27]Cisco, “End user license agreement”, [Online]. Avai lable:, He has been working full time for the poisoning vulnerability analysis and pointing out that they are 10.1007/9783642161612_27 vol. 5. no. 1, 2016, pp. 29–36, DOI: 10.11601/ijates.v5i1.138 transition technologies.Győr, Hungary since 1997. Now, he is an Associate Network address and protocol translation from IPv6 clients to http://www.cisco.com/c/en/us/products/enduserlicense Professor.Department He has been of working Telecommunications, part time for the [8] G. Lencse and Y. Kadobayashi, “Testbed for security analysis of [23] D. Bakai, “DebianVM”, [Online]. Available: not suitable for our purposes,X. C weONCLUSION have designed a methodology IPv4 servers”, IETF RFC 6146, Apr. 2011. DOI: agreement.html Dr. Lencse is a DepartmentmemberSzéchenyi of of IEICE Networked István (Institute Systems University, of andElect Services,ronics, Győr, the DNS64 IPv6 transition technology in virtual environment”, and implemented it in a testbed, which can be used for the 10.17487/rfc6146 [28]https://git.sch.bme.hu/bakaid/debianvmJuniper Networks, “End user license agreement”, [Online]. Information and CommunicationBudapestHungary University since Engineers, of 1997.Technology Japan). Now, and heEconomics, is an We have shown that DNS cache poisoning may be a crucial IEICE Communications Society Internet Architecture Workshop, [24]Internet Systems Consortium, “BIND: Versatile, Classic, systematic testing of DNS or DNS64 implementations, whether [6] G. Lencse, Y. Kadobayashi, “Methodology for the identification Available: http://www.juniper.net/support/eula/ Associate Professor.Budapest, He has Hungary been workingas a Senior part Research time for Fellow the vulnerability of DNS64 servers and we have given an Tokyo, Japan, Oct. 13, 2017, , vol. 117, no. 239, [29]CompleteThe 6NET Consortium, Name Server Ed. M. Software”, Dunmore, “An [Online]. IPv6 Deployment Available: they are susceptible to the above mentioned three of potential security issues of different IPv6 transition sinceDepartment 2005. At ofthe Networkedtime of writing Systems this paper and he was Services, a Guest Researcher Budapest introduction to the three main components of DNS cache pp.technologies: 1924. Threat analysis of DNS64 and stateful NAT64”, https://www.isc.org/downloads/bindGuide”, Sep. 2005. [Online]. Available: at the Laboratory for Cyber Resilience, Nara Institute of Science and vulnerabilities. University of Technology and Economics, Budapest, received Hungary his poisoning vulnerability, namely Transaction ID prediction, [9] G. Lencse and Y. , Kadobayashi, vol. 77, no. 1, “Benchmarking pp. 397411, August DNS64 1, [25]Freehttp://www.6net.org/book/deploymentguide.pdf Software Foundation, “The free software definition”, Technology, Japan, where his research area was the security analysis of We have selected BIND, PowerDNS, Unbound two versions Implementations: Theory and Practice”, [Online]. Available: http://www.gnu.org/philosophy/free IPv6 transition technologies. Ph.D. degree in computer science from source port number prediction, and a birthday paradox based 2018, DOI: 10.1016/j.cose.2018.04.012 [30]G. Lencse and S. Répás, “Improving the performance and security as a Senior Research Fellow since 2005. At the time of writing of TOTD, and mtd64ng for testing and also presented their [7] S. Son and V. Shmatikov,, vol. 127, “The no. 1, hitchhiker’s pp. 6174, guideSeptember to DNS 1, 2018,cache sw.en.htmlof the TOTD DNS64 implementation”, Dr.this Lencse paper is hea member was aof GuestIEICEOsaka (Institute Researcher University, of Electronics, at Japan, the Laboratory Information in 1997. and for attack, which is possible if a DNS or DNS64 server sends out Communication Engineers, Japan). setup. We have carried out their testing concerning the three DOI:poisoning”, 10.1016/j.comcom.2018.05.005 in [26]Open Source Initiative, “The ( open, Argentina), source definition vol. 14,”, no. [Online]. 1, Apr. Cyber Resilience, Nara InstituteHe is ofcurrently Science a and Professor Technology, in the multiple equivalent queries concurrently. [10]R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, “DNS Available: http://opensource.org/docs/osd possible components of the DNS cache poisoning vulnerability. 2014, ISSN: 16666038, pp. 9–15. Japan, where his researchGraduate area was the School security ofana lysis Information of IPv6 After surveying the available test tools for DNS cache Security Introduction and Requirements”, IETF RFC 4033, Mar. [27]Cisco,http://journal.info.unlp.edu.ar/journal/ “End user license agreement”, [Online]. Available: We have pointed out several vulnerabilities in TOTD and , Singapore, Sep. 7–9, 2010, pp. 466–483, DOI: Youki KadobayashiScience, Nara received Institute his ofPh.D. Science degree and in 2005. DOI: 10.17487/rfc4033 [31]http://www.cisco.com/c/en/us/products/enduserliceG. Lencse and D. Bakai, “Design, implementationnse and transition technologies. poisoning vulnerability analysis and pointing out that they are 10.1007/9783642161612_27 computer science from Osaka University, Japan, in mtd64ng. As they do not currently support caching, thus, cache [11]J. Linkova, “Let’s talk about IPv6 DNS64 & DNSSEC”, APNIC agreement.htmlperformance estimation of mtd64ng a new tiny DNS64 proxy”, Dr. Lencse is a memberTechnology, of IEICE Japan.(Institute Since of 2013,Electronics, he has not suitable for our purposes, we have designed a methodology [8] G. Lencse and Y. Kadobayashi, “Testbed for security analysis of 1997. He is currently a Professor in the Graduate poisoning is not possible in their cases. As the implementation Blog, 2016, https://blog.apnic.net/2016/06/09/letstalkipv6 [28]Juniper Networks, “End user license agreement”, [Online]. Information and Communicationalso been Engineers, working as Japan). the Rapporteur of and implemented it in a testbed, which can be used for the the DNS64 IPv6 transition technology in virtual environment”, , vol. 25, no. School of Information Science, Nara Institute of caching is included in the midterm development plans of dns64dnssec/ Available:2, Jun. 2017, http://www.juniper.net/support/eula/ pp. 91–102, DOI:10.20532/cit.2017.100 3419 ITUT Q.4/17 for cybersecurity systematic testing of DNS or DNS64 implementations, whether IEICE Communications Society Internet Architecture Workshop, of Science and Technology, Japan. Since 2013, mtd64ng, we have also given recommendations for the [12]C.Tokyo, Bao, Japan,C. Huitema, Oct. 13, M. 2017, Bagnulo, M Boucadair, vol.and 117,X. Li, no. “IPv6 239, [29][32]ThePowerdns.com 6NET Consortium, BV, Ed. “PowerDNS”, M. Dunmore, “An [Online]. IPv6 Deployment Available: standardization. Hishe has research also been interests working include as the cybRapporteurersecurity, of they are susceptible to the above mentioned three addressing of IPv4/IPv6 translators”, IETF RFC 6052, Oct. 2010. Guide”, Sep. 2005. [Online]. Available: elimination of its uncovered vulnerabilities. pp. 1924. http://www.powerdns.com web security, and distributedITU-T Q.4/17 systems. for cybersecurity standardization. received his vulnerabilities. DOI: 10.17487/rfc6052 [33]http://www.6net.org/book/deploymentguide.pdfNLnet Labs, “Unbound”, [Online]. Available: http:// unbound.net His research interests include cybersecurity, web As for BIND, PowerDNS, and Unbound, we have not found [9] G. Lencse and Y. Kadobayashi, “Benchmarking DNS64 Dr. Kadobayashi is Ph.D. a member degree of in IEEEcomputer Communications science from We have selected BIND, PowerDNS, Unbound two versions [13]A. Hubert, R. van Mook, “Measures for making DNS more [30][34]G.G. Lencse Lencse, and “Test S. Répás, program “Improving for the performance the performance analys andis of security DNS64 security, and distributed systems. any vulnerabilities that could lead to cache poisoning. Implementations: Theory and Practice”, society. of TOTD, and mtd64ng for testing and also presented their resilient against forged, vol. 127, answers”, no. 1, pp. IETF 6174, RFC September 5452, Jan. 1, 2009.2018, ofservers”, the TOTD DNS64 implementation”, Dr. KadobayashiOsaka University, is a Japan,member in 1997.of IEEE DOI: 10.17487/rfc5452 (, Argentina), vol. 14, no. 1, Apr. CommunicationsHe is society. currently a Professor in the setup. We have carried out their testing concerning the three DOI: 10.1016/j.comcom.2018.05.005 , vol. REFERENCES [14][10]M.R. Arends, Larsen, F.R. Gont,Austein, “Recommendations M. Larson, D. Massey, for transport S. Rose,protocol “DNS 2014,4, no. 3, 2015, ISSN: pp 60–65. DOI: 16666038, 10.11601/ijates.v4i3.121 pp. 9–15. Graduate School of Information possible components of the DNS cache poisoning vulnerability. port randomization”, IETF RFC 6056, Jan. 2011. DOI: http://journal.info.unlp.edu.ar/journal/ [1] E. Nordmark, R. Gilligan, “Basic transition mechanisms for IPv6 Security Introduction and Requirements”, IETF RFC 4033, Mar. Science, Nara Institute of Science and We have pointed out several vulnerabilities in TOTD and 10.17487/rfc6056 [31]G. Lencse and D. Bakai, “Design, implementation and hosts and routers”, IETF RFC 4213, October 2005. DOI: 2005. DOI: 10.17487/rfc4033 Technology, Japan. Since 2013, he has mtd64ng. As they do not currently support caching, thus, cache performance estimation of mtd64ng a new tiny DNS64 proxy”, 10.17487/rfc4213 [11]J. Linkova, “Let’s talk about IPv6 DNS64 & DNSSEC”, APNIC also been working as the Rapporteur of poisoning is not possible in their cases. As the implementation Blog, 2016, https://blog.apnic.net/2016/06/09/letstalkipv6 , vol. 25, no. of caching is included in the midterm development plans of dns64dnssec/ 2, Jun. 2017, pp. 91–102, DOI:10.20532/cit.2017.1003419 ITUT Q.4/17 for cybersecurity [12]C. Bao, C. Huitema, M. Bagnulo, M Boucadair and X. Li, “IPv6 [32]Powerdns.com BV, “PowerDNS”, [Online]. Available: standardization. His research interests include cybersecurity, mtd64ng, we have also given recommendations for the http://www.powerdns.com elimination of its uncovered vulnerabilities. addressing of IPv4/IPv6 translators”, IETF RFC 6052, Oct. 2010. web security, and distributed systems. DOI: 10.17487/rfc6052 [33]NLnet Labs, “Unbound”, [Online]. Available: http://unbound.net Dr. Kadobayashi is a member of IEEE Communications As for BIND, PowerDNS, and Unbound, we have not found [34]G. Lencse, “Test program for the performance analysis of DNS64 [13]A. Hubert, R. van Mook, “Measures for making DNS more society. any vulnerabilities that could lead to cache poisoning. resilient against forged answers”, IETF RFC 5452, Jan. 2009. servers”, DOI: 10.17487/rfc5452 , vol. REFERENCES [14]M. Larsen, F. Gont, “Recommendations for transportprotocol 4, no. 3, 2015, pp 60–65. DOI: 10.11601/ijates.v4i3.121 port randomization”, IETF RFC 6056, Jan. 2011. DOI: [1] E. Nordmark, R. Gilligan, “Basic transition mechanisms for IPv6 10.17487/rfc6056 hosts and routers”, IETF RFC 4213, October 2005. DOI: 10.17487/rfc4213
JUNE 2018 • VOLUME X • NUMBER 2 25