საუბარი გვექნება DDOS შეტევის ერთ-ერთ კლასზე DNS amplification DDOS

ისევე როგორც ping ფლუდი და Smurfing, DNS amplification იც “წარმატებული” მიზნის მისაღწევად საჭიროებენ დიდი მოცულობის მონაცემების გატარებას “მსხვერპლის” ქსელში, რის შედეგადაც ქსელში სისტემის გამართული მუშაობისთვის საჭირო მონაცემების ჩახშობა ხდება. შეტევის დასახელებაში amplification (გაძლიერება)  უბრალოდ სიტყვა არ არის, ამ შეტევის მთავარი პრინციპი იმალება ამ სიტყვის უკან. ზემოთ ხსნებული DDOS შეტევის მეთოდის გამოყენებისას შესაძლებელია მცირე მოცულობის მონაცემები (რამოდენიმე ბაიტი), რომ
გადავაქციოთ უფრო მეტი ზომის მონაცემების ნაკადათ. ერთ-ერთ კონფერენციაზე ერთ-ერთმა მონაწილემ აიღო 20 ბაიტის მოცულობის პაკეტი და ამ მეთოდის საშუალებით გადააქაცია 8.5K ბაიტის მოცულობის პაკეტად, თუ შევხედავთ თუ რაოდენ კოლოსალური ზრდადობა განიცადა საწყისმა პაკეტმა, ერთი შეხედვით ჩანს რომ ამ მეთოდის საშუალებით თქვენთვის სასურველ “მსხვერპლს ცხოვრებას გადაუქცევთ კოშმარად”.
DAD ეს შეტევის ის ტიპია რომელიც დღესაც ლიდერის პოზიციას იკავებს, DDOS შეტევის მასშტაბურობის(სიძლიერის) მიხედვით ინტერნეტის ისტორიაში.  ყოველ წელს სულ ახალ-ახალ სიმაღლეებს იპყრობს DAD თავისი მასშტაბირურობის და სიძლიერის მიხედვით.

   ჯერ-ჯერობით რეკორდი ინტერნეტის ისტორიაში უკავია 2010წელს განხორციელებულ DAD შეტევას, რეკორდი არის 100გბ/წ, რომლის მსხვერპლთა სიაში მოხვდა არა მარტო გიგანტი ვებ პორტალები არამედ ცალკეული ნაციონალური მაგისტრალური პროვაიდერები, ასევე შეტევისას განადგურდა ანტი დოს სერვისებიც, რომელთა ამოცანაც იყო ამ დარტყმის თავის თავზე აღება. მაშინ შეტევის ქვეშ მოყვა თვით ინტერნეტის ავტორი ორგანიზაცია DARPA.  მოკლედ DAD ეს არის DDos შეტევის მეთოდი რომლის მეშვეობითაც შესაძლებელია ვირტუალურ სამყაროში დამანგრეველი სიძლიერის “ცუნამის” გამოწვევა.
ეხლა მოკლედ პატარა ისტორია ჯერ კიდევ მაშინ, როდესაც ინტერნეტში ყველა ერთმანეთს ენდობოდა, ყველა “სხვა” (არა საკუთარი) მოთხოვნაზე ქსელში მიღებული წესი იყო (ნორმალურად ითვლებოდა) პასუხი დაბრუნებულიყო –
“შეგიძლია პატიოსნად ისარგებლო ჩემი სერვისით თუ შენ ეს გჭირდება” ესეთ დროს ჩაფიქრებულ იყო და განხორციელდა შესანიშნავი ინტერნეტ სერვისი DNS. DNS იძლევა საშუალებას ადამიანისთვის გასაგებ ენაზე არსებული დომენური სახელწოდებები მოიყვანოს შესაბამისობაში კომპიუტერისთვის გასაგებ ფორმაში და პირიქით.
სხვა ინტერნეტ-სერვისებისგან განსხვავებით DNS ეს არის დამაკავშირებელი ხერხემალი ინტერნეტისთვის. ბევრი არც დაფიქრებულა ამაზე მაგრამ DNS ასე თუ ისე ირიბად გამოიყენება თითქმის ყველას სერვისსა თუ პროტოკოლში. დღეს-დღეობით რეალობა კიდე ისეთია რომ DNS კრიმინალური მიზნებისათვისაც იყენებენ.
საერთო სქემა DNSის მუშაობის არის შემდეგი
1. მომხმარებელი ითხოვს DNS სერვერისგან (როგორც წესი DNS სერვერი მომხმარებლისთვის მოწოდებულია ინტერნეტ სერვისის მომწოდებელი პროვაიდერისგან, რომლის ინტერნეტ შემოთავაზებითაც სარგებლობს მომხმარებელი) IP მისამართს მისთვის საჭირო დომენის webserver.com.
   შემდეგისთვის ეს DNS სერვერი (როგორც წესი რომელიც ინტერნეტ სერვისის მომწოდებელი პროვაიდერისგან არის მოწოდებული)  ავღნიშნოთ როგორც User Primary DNS Server.
2. თუ ზემოთ ხსენებული DNS სერვერი  არის არა ავტორიტეტული მოთხოვნილი დომენისთვის , და არ შეიცავს მოთხოვნილ მისამართს თავის დრობით კეშში, თავის მხრივ კიდე ეს სერვერი მუშაობს რეკურსიულ რეჟიმში (ეს მართებულია დიდი ნაწილი მსგავსი ტიპის დნს სერვერებისთვის)-მაშინ ეს მოთხოვნა იგზავნება უკვე  User Primary DNS Server სახელით უკვე რამოდენიმე ძირითად DNS სერვერებთაგან ერთ ერთზე (ეს სერვერები ცნობილია როგორც Root DNS Server და წარმოადგენს ინტერნეტ სერვისის ხერხემალს,
ამ სერვერების გათიშვის შემთხვევაში ინტერნეტ სერვისი როგორი სახითაც ვიცნობთ გაითიშება. მსგავს სერვერებზე შეტევის მცდელობა ქონდათ 2002 წელს, რომელიც გრძელდებოდა 1 საათს და მაშინ 13 root dns serverს შეტევის ტიპიდან გამომდინარე დიდი ზიანი არ მიუღიათ, მსგავსი მცდელობა იყო 2007 წელს და 2 root dns სერვერს მიადგა ზიანი, მსგავსი მცდელობის გამეორება სურდათ 2012 ში Anonymous
მაგრამ საპირველ აპრილო ხუმრობა იყო ეს თუ რეალურად სურდათ და არ გამოუვიდათ ჩანაფიქრი არვიცი 🙂 )
3. თუ Root DNS serverს არ აქვს მონაცემები რომელიც მოთხოვნას შეესაბამება მაშინ ის User Primary DNS Server უბრუნებს პასუხად მინიშნებას თუ რომელ დნს სერვერზე უნდა მოიძიოს  პასუხი  თავის მოთხოვნა რომ დაკმაყოფილდეს,
თავის მხრივ მინიშნებაში არსებული დნს სერვერი (TLD) ეს არის მმართველი იმ დომენური ზონის რომელი დომენური ზონის დომენის იპ მისამართის მოთხოვნაც ხდება , ჩვენს შემთხვევაში .com დომენური ზონის მმართველი დნს სერვერის მისამართი დაბრუნდებოდა
4. User Primary DNS Server როდესაც მიიღებს მინიშნებას პასუხად, თუ სად უნდა გადაამისამართოს თავისი მოთხოვნა რომელ დნს სერვერზე, აგზავნის მოთხოვნას უკვე იმ დნს სერვერთან რომელიც პასუხს აგებს ჩვენს შემთხვევაში .com დომენურ ზონაზე.
5. შესაძლებელია .com ზონაზე პასუხისმგებელმა DNS სერვერმაც ვერ იპოვოს მსგავსი ჩანაწერი თავისთან და მაშინ ის პასუხად აბრუნებს მისამართს ამ დომენისთვის ავტორიტეტულ დნს სერვერის მისამართს რომელსაც დავარქვათ Domain Primary DNS Server;
6. User Primary DNS Server როდესაც მიიღებს მორიგ მინიშნებას შეეცდება უკვე პირდაპირ გააგზავნოს მოთხოვნა Domain Primary DNS Serverთან.
7. და ბოლოს Domain Primary DNS Server აბრუნებს პასუხად მოთხოვნილი დომენის იპ მისამართს.
8. ზემოთ მოყვანილი მცდელობების შედეგად უკვე User Primary DNS Server ს შეუძლია უკვე წარმატებით დაუბრუნოს მოთხოვნილი დომენის (webserver.com) IP მისამართი  თავის მომხმარებელს და დაამთავროს მოთხოვნის რეკურსიული დამუშავება.
ddn
რა თქმა უნდა ზემოთ მოყვანილი დნს სერვერის მუშაობის სქემა ეს არის სტანდარტული სქემა რის მიხედვითაც ძირითადად მუშაობენ დნს ები. რეალურ პირობებში კიდე ეს სქემა შეიძლება მუშაობდეს ცოტა სახეცვლილებებით, რომელიც დამოკიდებულია ამა თუ იმ დნს სერვერის
დაკონფიგურირებულ კონფიგურაციაზე.
 ჩვენ უკვე განვიხილეთ დნს ის სტანდარტული მუშაობის პრინციპები და მიმდევრობა და ეხლა უკვე განვიხილოთ მისი სუსტი ადგილები და შესაბამისად განვიხლოთ თუ როგორ ხდება ამ სისუსტეების გამოყენება DDos ისთვის.
  განვიხილოთ DAD ის მუშაობის დინამიკა.
  DADის ერთ-ერთ საინტერესო თვისებას წარმოადგენს, ის რომ არ არის აუცილებელი გვქონდეს ჩვენი ბოტნეტების ინფრასტრუქტურა. წარმატებული შედეგის მისაღწევად საკმარისია ინტერნეტთან ცოტათი ჩქარი შეერთების კანალზე ვიყოთ და შემდეგ გამოვიყენოთ DDos შეტევის
  გაძლიერების ეფექტი ქვემოთ მოყვანილი სქემის მიხედვით.
  სიტუაცია დრამატულად იცვლება თუ ამ საქმეში ბოტნეტებს ჩავრთავთ. განვიხლოთ როგორ ხდება ეს ყველაფერი.
  1. შემტევი აგზავნის მოთხოვნას თავის ბოტნეტებთან, შეასრულონ მოთხოვნათა ციკლი დნსზე.
  2. ყველა “ზომბი” კომპიუტერი (ბოტნეტი სადაც დგას)  იწყებენ მოთხოვნების სერიის გაგზავნას ყველა თავის User Primary DNS Server თან, ოღონდ ის ip მისამართი (ნორმალურ შემთხვევაში ის კომპიუტერის მისამართია რომელიც იწყებს მოთხოვნის გაგზავნას)
  პასუხი სადაც უნდა დააბრუნოს User Primary DNS Server მა არის “შეცვლილი” მსხვერპლის ip მისამართით (ip spoofing).
  3. აქ უკვე გამოვტოვებ იმ ეტაპს თუ რა ხდება და როგორ ეძებს User Primary DNS Server პასუხს მისთვის გაგზავნილ მოთხოვნაზე, ეს უკვე განვიხილეთ ზემოთ, დნს მუშაობის პრინციპის ახსნისას.
  4. შედეგად როცა პასუხს იპოვის User Primary DNS Server მისთვის გაგზავნილ მოთხოვნაზე ის შეეცდება პასუხი დააბრუნოს მსხვერპლის კომპიუტერზე (გახსოვთ ალბათ ბოტნეტი მოთხოვნის გაგზავნის წინ თავის იპ მისამართს ცვლის მსხვერპლის იპზე რათა პასუხი დაბრუნდეს მსხვერპლის კომპიუტერზე)
  5. შესაბამისად ვღებულობთ, რომ რამოდენიმე ბოტნეტის მიერ გაგზავნილი მოთხოვნა User Primary DNS Server ზე, აბრუნებს პასუხს 1 მსხვერპლის კომპიუტერზე.
15533b6e085c.png
  შეტევის ძირითადი არსი რომ არ დაიკარგოს გამოვყოთ 3 ძირითადი მომენტი რომელიც იძლევა საშუალებას განხორციელდეს ეფექტური DDos შეტევა DNS ის საშუალებით, რის შედეგადაც ვღებულობთ ე.წ DAD შეტევის მეთოდს.
  1. არეკვლის ეფექტი: სპუფინგის გამოყენებით ხდება ip მისამართის შეცვლა რის შედეგადაც ყველა პასუხად დაბრუნებული პაკეტის გადამისამართება ხდება მსხვერპლზე.
     სპუფინგი შესაძლებელია იმის გამო რომ დნს არქიტექტურის თავისებურებიდან გამომდინარე შესაძლებელია, მოთხოვნიგ გაგზავნა იმ პროტოკოლოს გამოყენებით რომლებიც არ საჭიროებს handshake (როგორც წესი დნს მოთხოვნები udp პროტოკოლის მეშვეობით გადაიცემა)
     რახან არ საჭიროებს handshake შესაბამისად შესაძლებელია მომთხოვნის რეალური მისამართის შეცვლა მსხვერპლის მისამართზე.
  2. შეტევის გაძლიერების კოფიეციენტი (amplification factor): ეს კოეფიციენტი ესე ვთქვათ ჩვენთვის სასურველ პირობებში არის 73 (ძირითადად კიდე 30-60 შორის). რას ნიშნავს ეხლა ეს?
    ეს ნიშნავს იმას რომ ყოველ გაგზავნილ 1 ბაიტ მოთხოვნაზე, ზემოთ მოყვანილი სქემა არასწორად დაკონფიგურირებული დნს სერვერების გამო დააბრუნებს 30-60 ბაიტიან პასუხს დააბრუნებენ, რაც იძლევა შეტევის გაძლიერების ეფექტს.
ანუ თვითონ დნს თან მოთხოვნის მოცულობის ზომა ბაიტებში გაცილებით ნაკლებია იმასთან შედარებით რასაც პასუხად დნს სერვერი აბრუნებს.
მაგ. მოთხოვნა dig ANY isc.org @x.x.x.x პასუხად აბრუნებს “გიგანტურ” პასუხს
; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5


;; QUESTION SECTION:
;isc.org.                        IN        ANY


;; ANSWER SECTION:
isc.org.                4084       IN        SOA          ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org.                4084       IN        A            149.20.64.42
isc.org.                4084       IN        MX           10 mx.pao1.isc.org.
isc.org.                4084       IN        MX           10 mx.ams1.isc.org.
isc.org.                4084       IN        TXT          "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org.                4084       IN        TXT          "$Id: isc.org,v 1.1724 2012-10-23 00:36:09 bind Exp $"
isc.org.                4084       IN        AAAA         2001:4f8:0:2: 
isc.org.                4084       IN        NAPTR        20 0 "S" "SIP+D2U" "" _sip._udp.isc.org.
isc.org.                484        IN        NSEC         _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY SPF
isc.org.                4084       IN        DNSKEY       256 3 5 BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
isc.org.                4084       IN        DNSKEY       257 3 5 BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+ u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3 47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz Bkj0BrN/9Bexjpiks3jRhZatEsXn3dTy47R09Uix5WcJt+xzqZ7+ysyL KOOedS39Z7SDmsn2eA0FKtQpwA6LXeG2w+jxmw3oA8lVUgEf/rzeC/bB yBNsO70aEFTd
isc.org.                4084       IN        SPF          "v=spf1 a mx ip4:204.152.184.0/21 ip4:149.20.0.0/16 ip6:2001:04F8::0/32 ip6:2001:500:60::65/128 ~all"
isc.org.                484        IN        RRSIG        NS 5 2 7200 20121125230752 20121026230752 4442 isc.org. oFeNy69Pn+/JnnltGPUZQnYzo1YGglMhS/SZKnlgyMbz+tT2r/2v+X1j AkUl9GRW9JAZU+x0oEj5oNAkRiQqK+D6DC+PGdM2/JHa0X41LnMIE2NX UHDAKMmbqk529fUy3MvA/ZwR9FXurcfYQ5fnpEEaawNS0bKxomw48dcp Aco=
isc.org.                484        IN        RRSIG        SOA 5 2 7200 20121125230752 20121026230752 4442 isc.org. S+DLHzE/8WQbnSl70geMYoKvGlIuKARVlxmssce+MX6DO/J1xdK9xGac XCuAhRpTMKElKq2dIhKp8vnS2e+JTZLrGl4q/bnrrmhQ9eBS7IFmrQ6s 0cKEEyuijumOPlKCCN9QX7ds4siiTIrEOGhCaamEgRJqVxqCsg1dBUrR hKk=
isc.org.                484        IN        RRSIG        MX 5 2 7200 20121125230752 20121026230752 4442 isc.org. VFqFWRPyulIT8VsIdXKMpMRJTYpdggoGgOjKJzKJs/6ZrxmbJtmAxgEu /rkwD6Q9JwsUCepNC74EYxzXFvDaNnKp/Qdmt2139h/xoZsw0JVA4Z+b zNQ3kNiDjdV6zl6ELtCVDqj3SiWDZhYB/CR9pNno1FAF2joIjYSwiwbS Lcw=
isc.org.                484        IN        RRSIG        TXT 5 2 7200 20121125230752 20121026230752 4442 isc.org. Ojj8YCZf3jYL9eO8w4Tl9HjWKP3CKXQRFed8s9xeh5TR3KI3tQTKsSeI JRQaCXkADiRwHt0j7VaJ3xUHa5LCkzetcVgJNPmhovVa1w87Hz4DU6q9 k9bbshvbYtxOF8xny/FCiR5c6NVeLmvvu4xeOqSwIpoo2zvIEfFP9deR UhA=
isc.org.                484        IN        RRSIG        AAAA 5 2 7200 20121125230752 20121026230752 4442 isc.org. hutAcro0NBMvKU/m+2lF8sgIYyIVWORTp/utIn8KsF1WOwwM2QMGa5C9 /rH/ZQBQgN46ZMmiEm4LxH6mtaKxMsBGZwgzUEdfsvVtr+fS5NUoA1rF wg92eBbInNdCvT0if8m1Sldx5/hSqKn8EAscKfg5BMQp5YDFsllsTauA 8Y4=
isc.org.                484        IN        RRSIG        NAPTR 5 2 7200 20121125230752 20121026230752 4442 isc.org. ZD14qEHR7jVXn5uJUn6XR9Lvt5Pa7YTEW94hNAn9Lm3Tlnkg11AeZiOU 3woQ1pg+esCQepKCiBlplPLcag3LHlQ19OdACrHGUzzM+rnHY50Rn/H4 XQTqUWHBF2Cs0CvfqRxLvAl5AY6P2bb/iUQ6hV8Go0OFvmMEkJOnxPPw 5i4=
isc.org.                484        IN        RRSIG        NSEC 5 2 3600 20121125230752 20121026230752 4442 isc.org. rY1hqZAryM045vv3bMY0wgJhxHJQofkXLeRLk20LaU1mVTyu7uair7jb MwDVCVhxF7gfRdgu8x7LPSvJKUl6sn731Y80CnGwszXBp6tVpgw6oOcr Pi0rsnzC6lIarXLwNBFmLZg2Aza6SSirzOPObnmK6PLQCdmaVAPrVJQs FHY=
isc.org.                484        IN        RRSIG        DNSKEY 5 2 7200 20121125230126 20121026230126 4442 isc.org. i0S2MFqvHB3wOhv2IPozE/IQABM/eDDCV2D7dJ3AuOwi1A3sbYQ29XUd BK82+mxxsET2U6hv64crpbGTNJP3OsMxNOAFA0QYphoMnt0jg3OYg+AC L2j92kx8ZdEhxKiE6pm+cFVBHLLLmXGKLDaVnffLv1GQIl5YrIyy4jiw h0A=
isc.org.                484        IN        RRSIG        DNSKEY 5 2 7200 20121125230126 20121026230126 12892 isc.org. j1kgWw+wFFw01E2z2kXq+biTG1rrnG1XoP17pIOToZHElgpy7F6kEgyj fN6e2C+gvXxOAABQ+qr76o+P+ZUHrLUEI0ewtC3v4HziMEl0Z2/NE0MH qAEdmEemezKn9O1EAOC7gZ4nU5psmuYlqxcCkUDbW0qhLd+u/8+d6L1S nlrD/vEi4R1SLl2bD5VBtaxczOz+2BEQLveUt/UusS1qhYcFjdCYbHqF JGQziTJv9ssbEDHT7COc05gG+A1Av5tNN5ag7QHWa0VE+Ux0nH7JUy0N ch1kVecPbXJVHRF97CEH5wCDEgcFKAyyhaXXh02fqBGfON8R5mIcgO/F DRdXjA==
isc.org.                484        IN        RRSIG        SPF 5 2 7200 20121125230752 20121026230752 4442 isc.org. IB/bo9HPjr6aZqPRkzf9bXyK8TpBFj3HNQloqhrguMSBfcMfmJqHxKyD ZoLKZkQk9kPeztau6hj2YnyBoTd0zIVJ5fVSqJPuNqxwm2h9HMs140r3 9HmbnkO7Fe+Lu5AD0s6+E9qayi3wOOwunBgUkkFsC8BjiiGrRKcY8GhC kak=
isc.org.                484        IN        RRSIG        A 5 2 7200 20121125230752 20121026230752 4442 isc.org. ViS+qg95DibkkZ5kbL8vCBpRUqI2/M9UwthPVCXl8ciglLftiMC9WUzq Ul3FBbri5CKD/YNXqyvjxyvmZfkQLDUmffjDB+ZGqBxSpG8j1fDwK6n1 hWbKf7QSe4LuJZyEgXFEkP16CmVyZCTITUh2TNDmRgsoxrvrOqOePWhp 8+E=
isc.org.                4084       IN        NS           ns.isc.afilias-nst.info.
isc.org.                4084       IN        NS           ams.sns-pb.isc.org.
isc.org.                4084       IN        NS           ord.sns-pb.isc.org.
isc.org.                4084       IN        NS           sfba.sns-pb.isc.org.


;; AUTHORITY SECTION:
isc.org.                4084       IN        NS           ns.isc.afilias-nst.info.
isc.org.                4084       IN        NS           ams.sns-pb.isc.org.
isc.org.                4084       IN        NS           ord.sns-pb.isc.org.
isc.org.                4084       IN        NS           sfba.sns-pb.isc.org.


;; ADDITIONAL SECTION:
mx.ams1.isc.org.        484        IN        A            199.6.1.65
mx.ams1.isc.org.        484        IN        AAAA         2001:500:60::65
mx.pao1.isc.org.        484        IN        A            149.20.64.53
mx.pao1.isc.org.        484        IN        AAAA         2001:4f8:0:2::2b
_sip._udp.isc.org.      4084       IN        SRV          0 1 5060 asterisk.isc.org.


;; Query time: 176 msec
;;SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE  rcvd: 3223
64 ბაიტიანი მოთხოვნა დნს სერვერზე და პასუხად მივიღეთ 3,223 ბაიტიანი პასუხი რომელიც გაეგზავნა მსხვერპლს. ანუ მივიღეთ გაძლიერების ეფექტი.
  3. პრობლემა open resolver: ხშირ შემთხვევაში ეს არის მოძველებული დნს სერვერის ვერსია ან უბრალოდ არასწორად დაკონფიგურირებული ეგზემპლიარი. რის შედეგადაც შესაძლებელია მოთხოვნების მიღება სხვა ქსელიდან, მათთვის მოთხოვნის
    რეკურსიული დამუშავება, და პასუხის გაგზავნა ყოველგვარი შემოწმების გარეშე. ჩვენს შემთხვევაში ეს სუსტი წერტილი არის User Primary DNS Server.
წყარო:scripts.ge