ភាពយឺតយ៉ាវ DNS ទាបគឺជាគន្លឹះក្នុងការរុករកអ៊ីនធឺណិតលឿន។ ដើម្បីបង្រួមអប្បបរមាវាមានសារៈសំខាន់ណាស់ក្នុងការជ្រើសរើសម៉ាស៊ីនមេ DNS ដោយប្រុងប្រយ័ត្ននិង ការបញ្ជូនតអនាមិក. ប៉ុន្តែជំហានដំបូងគឺត្រូវកម្ចាត់សំណួរដែលគ្មានប្រយោជន៍។

នេះជាមូលហេតុដែល DNS ត្រូវបានរចនាឡើងដំបូងជាពិធីការដែលអាចលាក់ទុកបានខ្ពស់។ អ្នកគ្រប់គ្រងតំបន់កំណត់ពេលវេលាដើម្បីបន្តផ្ទាល់ (TTL) សម្រាប់ធាតុនីមួយៗ ហើយអ្នកដោះស្រាយប្រើព័ត៌មាននេះនៅពេលរក្សាទុកធាតុនៅក្នុងអង្គចងចាំ ដើម្បីជៀសវាងចរាចរណ៍ដែលមិនចាំបាច់។

តើឃ្លាំងសម្ងាត់មានប្រសិទ្ធភាពទេ? កាលពីប៉ុន្មានឆ្នាំមុន ការស្រាវជ្រាវតិចតួចរបស់ខ្ញុំបានបង្ហាញថាវាមិនល្អឥតខ្ចោះទេ។ សូមក្រឡេកមើលស្ថានភាពបច្ចុប្បន្ន។

ដើម្បីប្រមូលព័ត៌មានខ្ញុំបានជួសជុល ម៉ាស៊ីនមេ DNS ដែលបានអ៊ិនគ្រីប ដើម្បីរក្សាទុកតម្លៃ TTL សម្រាប់ការឆ្លើយតប។ វាត្រូវបានកំណត់ថាជា TTL អប្បបរមានៃកំណត់ត្រារបស់វាសម្រាប់សំណើចូលនីមួយៗ។ នេះផ្តល់នូវទិដ្ឋភាពទូទៅដ៏ល្អនៃការចែកចាយ TTL នៃចរាចរណ៍ពិតប្រាកដ ហើយក៏គិតគូរពីប្រជាប្រិយភាពនៃសំណើបុគ្គលផងដែរ។ កំណែដែលបានជួសជុលរបស់ម៉ាស៊ីនមេបានដំណើរការអស់រយៈពេលជាច្រើនម៉ោង។

សំណុំទិន្នន័យលទ្ធផលមាន 1 កំណត់ត្រា (ឈ្មោះ, qtype, TTL, ត្រាពេលវេលា)។ នេះគឺជាការចែកចាយ TTL ទាំងមូល (អ័ក្ស X គឺ TTL គិតជាវិនាទី)៖

ក្រៅពីការប៉ះទង្គិចតិចតួចនៅ 86 (ភាគច្រើនសម្រាប់កំណត់ត្រា SOA) វាច្បាស់ណាស់ថា TTLs ស្ថិតនៅក្នុងជួរទាប។ តោះមើលឲ្យកាន់តែច្បាស់៖

មិនអីទេ TTLs ធំជាង 1 ម៉ោងមិនសំខាន់ជាស្ថិតិទេ។ បន្ទាប់មកយើងផ្តោតលើជួរ 0-3600៖

TTL ភាគច្រើនគឺពី 0 ទៅ 15 នាទី៖

ភាគច្រើនគឺពី 0 ទៅ 5 នាទី:

វាមិនល្អខ្លាំងណាស់។

ការចែកចាយបណ្តុំធ្វើឱ្យបញ្ហាកាន់តែច្បាស់៖

ពាក់កណ្តាលនៃការឆ្លើយតប DNS មាន TTL នៃ 1 នាទី ឬតិចជាងនេះ ហើយបីភាគបួនមាន TTL នៃ 5 នាទី ឬតិចជាងនេះ។

ប៉ុន្តែ​ចាំ​មើល វា​ពិត​ជា​អាក្រក់​ជាង។ យ៉ាងណាមិញនេះគឺជា TTL ពីម៉ាស៊ីនមេដែលមានការអនុញ្ញាត។ ទោះយ៉ាងណាក៏ដោយ អ្នកដោះស្រាយម៉ាស៊ីនភ្ញៀវ (ឧ. រ៉ោតទ័រ ឃ្លាំងសម្ងាត់មូលដ្ឋាន) ទទួលបាន TTL ពីកម្មវិធីដោះស្រាយចរន្ត ហើយវាថយចុះជារៀងរាល់វិនាទី។

ដូច្នេះអតិថិជនពិតជាអាចប្រើប្រាស់ធាតុនីមួយៗសម្រាប់ជាមធ្យមពាក់កណ្តាល TTL ដើម មុនពេលផ្ញើសំណើថ្មី។

ប្រហែលជា TTLs ទាបបំផុតទាំងនេះអនុវត្តចំពោះសំណើមិនធម្មតា ហើយមិនមែនជាគេហទំព័រពេញនិយម និង API ទេ? តោះទស្សនាទាំងអស់គ្នា៖

អ័ក្ស X គឺ TTL ហើយអ័ក្ស Y គឺជាសំណួរពេញនិយម។

ជាអកុសល សំណួរពេញនិយមបំផុតក៏ជាឃ្លាំងសម្ងាត់ដ៏អាក្រក់បំផុតផងដែរ។

តោះពង្រីក៖

សាលក្រម៖ វាពិតជាអាក្រក់ណាស់។ ពីមុនវាអាក្រក់រួចទៅហើយ ប៉ុន្តែវាកាន់តែអាក្រក់ទៅៗ។ ឃ្លាំងសម្ងាត់ DNS បានក្លាយទៅជាគ្មានប្រយោជន៍។ ដោយសារមនុស្សតិចប្រើឧបករណ៍ដោះស្រាយ DNS របស់ ISP របស់ពួកគេ (សម្រាប់ហេតុផលល្អ) ការកើនឡើងនៃភាពយឺតយ៉ាវកាន់តែគួរឱ្យកត់សម្គាល់។

ឃ្លាំងសម្ងាត់ DNS បានក្លាយទៅជាមានប្រយោជន៍សម្រាប់តែមាតិកាដែលគ្មាននរណាម្នាក់ចូលមើល។

សូមចំណាំផងដែរថាកម្មវិធីអាច នៅក្នុងវិធីផ្សេងគ្នា បកស្រាយ TTLs ទាប។

ហេតុអ្វីអញ្ចឹង។

ហេតុអ្វីបានជាកំណត់ត្រា DNS ត្រូវបានកំណត់ទៅជា TTL ទាបបែបនេះ?

• ឧបករណ៍តុល្យភាពបន្ទុកចាស់ត្រូវបានទុកចោលជាមួយនឹងការកំណត់លំនាំដើម។
• មានទេវកថាដែលតុល្យភាពការផ្ទុក DNS អាស្រ័យលើ TTL (នេះមិនមែនជាការពិតទេ - ចាប់តាំងពីថ្ងៃនៃ Netscape Navigator អតិថិជនបានជ្រើសរើសអាសយដ្ឋាន IP ចៃដន្យពីសំណុំនៃ RRs ហើយបានសាកល្បងដោយតម្លាភាពប្រសិនបើពួកគេមិនអាចភ្ជាប់)
• អ្នកគ្រប់គ្រងចង់អនុវត្តការផ្លាស់ប្តូរភ្លាមៗ ដូច្នេះវាកាន់តែងាយស្រួលក្នុងការរៀបចំផែនការ។
• អ្នកគ្រប់គ្រងម៉ាស៊ីនមេ DNS ឬ load balancer មើលឃើញថាភារកិច្ចរបស់គាត់កំពុងដាក់ពង្រាយការកំណត់រចនាសម្ព័ន្ធដែលអ្នកប្រើប្រាស់ស្នើសុំយ៉ាងមានប្រសិទ្ធភាព និងមិនបង្កើនល្បឿនគេហទំព័រ និងសេវាកម្ម។
• TTL ទាបផ្តល់ឱ្យអ្នកនូវសន្តិភាពនៃចិត្ត។
• មនុស្សដំបូងកំណត់ TTLs ទាបសម្រាប់ការធ្វើតេស្ត ហើយបន្ទាប់មកភ្លេចផ្លាស់ប្តូរវា។

ខ្ញុំមិនបានបញ្ចូល "failover" នៅក្នុងបញ្ជីទេ ព្រោះវាកាន់តែតិចទៅៗ។ ប្រសិនបើអ្នកត្រូវការប្តូរទិសអ្នកប្រើប្រាស់ទៅកាន់បណ្តាញផ្សេងទៀតដើម្បីបង្ហាញទំព័រកំហុស នៅពេលដែលអ្វីៗផ្សេងទៀតត្រូវបានខូច ការពន្យារពេលលើសពី 1 នាទីគឺប្រហែលជាអាចទទួលយកបាន។

លើសពីនេះ TTL មួយនាទីមានន័យថា ប្រសិនបើម៉ាស៊ីនមេ DNS ដែលមានការអនុញ្ញាតត្រូវបានរារាំងលើសពី 1 នាទី នោះគ្មាននរណាម្នាក់នឹងអាចចូលប្រើសេវាកម្មដែលពឹងផ្អែកបានទេ។ ហើយ​ការ​ប្រើ​ដដែលៗ​នឹង​មិន​អាច​ជួយ​បាន​ទេ ប្រសិនបើ​មូលហេតុ​គឺ​ជា​កំហុស​ក្នុង​ការ​កំណត់​រចនាសម្ព័ន្ធ ឬ​ការ​លួច​ចូល។ ម្យ៉ាងវិញទៀត ជាមួយនឹង TTLs ដែលសមហេតុផល អតិថិជនជាច្រើននឹងបន្តប្រើការកំណត់ពីមុន ហើយមិនដែលកត់សំគាល់អ្វីទាំងអស់។

សេវាកម្ម CDN និងឧបករណ៍ផ្ទុកតុល្យភាពត្រូវស្តីបន្ទោសយ៉ាងទូលំទូលាយចំពោះ TTLs ទាប ជាពិសេសនៅពេលដែលពួកគេបញ្ចូលគ្នានូវ CNAMEs ជាមួយ TTLs ទាប និងកំណត់ត្រាជាមួយនឹង TTLs ទាបស្មើគ្នា (ប៉ុន្តែឯករាជ្យ)៖

$ drill raw.githubusercontent.com
raw.githubusercontent.com.	9	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	20	IN	A	151.101.128.133
github.map.fastly.net.	20	IN	A	151.101.192.133
github.map.fastly.net.	20	IN	A	151.101.0.133
github.map.fastly.net.	20	IN	A	151.101.64.133

នៅពេលណាដែល CNAME ឬកំណត់ត្រា A ណាមួយផុតកំណត់ សំណើថ្មីត្រូវតែត្រូវបានផ្ញើ។ ទាំងពីរមាន TTL 30 វិនាទី ប៉ុន្តែវាមិនដូចគ្នាទេ។ TTL ជាមធ្យមពិតប្រាកដនឹងមាន 15 វិនាទី។

ប៉ុន្តែចាំមើល! វាកាន់តែអាក្រក់ទៅទៀត។ អ្នកដោះស្រាយមួយចំនួនមានឥរិយាបទមិនល្អក្នុងស្ថានភាពនេះជាមួយនឹង TTL ទាបពីរដែលពាក់ព័ន្ធ៖

$drill raw.githubusercontent.com @4.2.2.2
raw.githubusercontent.com ។ 1 ក្នុង CNAME github.map.fastly.net ។
github.map.fastly.net ។ 1 ក្នុង A 151.101.16.133

ឧបករណ៍ដោះស្រាយកម្រិត 3 ប្រហែលជាដំណើរការលើ BIND ។ ប្រសិនបើអ្នកបន្តផ្ញើសំណើនេះ TTL នៃ 1 នឹងត្រូវបានបញ្ជូនមកវិញជានិច្ច។ ជាសំខាន់ raw.githubusercontent.com មិន​ដែល​បាន​ទុក​ក្នុង​ឃ្លាំង​សម្ងាត់។

នេះគឺជាឧទាហរណ៍មួយទៀតនៃស្ថានភាពបែបនេះជាមួយនឹងដែនពេញនិយមខ្លាំង៖

$ drill detectportal.firefox.com @1.1.1.1
detectportal.firefox.com.	25	IN	CNAME	detectportal.prod.mozaws.net.
detectportal.prod.mozaws.net.	26	IN	CNAME	detectportal.firefox.com-v2.edgesuite.net.
detectportal.firefox.com-v2.edgesuite.net.	10668	IN	CNAME	a1089.dscd.akamai.net.
a1089.dscd.akamai.net.	10	IN	A	104.123.50.106
a1089.dscd.akamai.net.	10	IN	A	104.123.50.88

យ៉ាងហោចណាស់មានកំណត់ត្រា CNAME ចំនួនបី។ អាយ។ មួយមាន TTL សមរម្យ ប៉ុន្តែវាគ្មានប្រយោជន៍ទាំងស្រុង។ CNAMEs ផ្សេងទៀតមាន TTL ដំបូង 60 វិនាទី ប៉ុន្តែសម្រាប់ដែន akamai.net TTL អតិបរមាគឺ 20 វិនាទី ហើយគ្មាននរណាម្នាក់ក្នុងចំណោមពួកគេស្ថិតក្នុងដំណាក់កាលនោះទេ។

ចុះ​ដែន​ដែល​ស្ទង់​មតិ​ឧបករណ៍ Apple ឥត​ឈប់ឈរ​វិញ?

$ drill 1-courier.push.apple.com @4.2.2.2
1-courier.push.apple.com.	1253	IN	CNAME	1.courier-push-apple.com.akadns.net.
1.courier-push-apple.com.akadns.net.	1	IN	CNAME	gb-courier-4.push-apple.com.akadns.net.
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.84
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.85

បញ្ហាដូចគ្នានឹង Firefox និង TTL នឹងត្រូវជាប់គាំងនៅ 1 វិនាទីភាគច្រើននៅពេលប្រើកម្មវិធីដោះស្រាយកម្រិត 3 ។

Dropbox?

$drill client.dropbox.com @8.8.8.8
client.dropbox.com ។ 7 នៅក្នុង CNAME client.dropbox-dns.com ។
client.dropbox-dns.com ។ 59 IN A 162.125.67.3

$drill client.dropbox.com @4.2.2.2
client.dropbox.com ។ 1 នៅក្នុង CNAME client.dropbox-dns.com ។
client.dropbox-dns.com ។ 1 IN A 162.125.64.3

នៅឯការថត safebrowsing.googleapis.com តម្លៃ TTL គឺ 60 វិនាទី ដូចជា Facebook domains។ ហើយម្តងទៀតតាមទស្សនៈរបស់អតិថិជនតម្លៃទាំងនេះត្រូវបានកាត់បន្ថយពាក់កណ្តាល។

តើធ្វើដូចម្តេចអំពីការកំណត់ TTL អប្បបរមា?

ដោយប្រើឈ្មោះ ប្រភេទសំណើ TTL និងត្រាពេលវេលាដែលបានរក្សាទុកដំបូង ខ្ញុំបានសរសេរស្គ្រីបដើម្បីក្លែងធ្វើសំណើចំនួន 1,5 លានដែលឆ្លងកាត់ឧបករណ៍ដោះស្រាយឃ្លាំងសម្ងាត់ ដើម្បីប៉ាន់ប្រមាណបរិមាណនៃសំណើដែលមិនចាំបាច់ដែលបានផ្ញើដោយសារតែការបញ្ចូលឃ្លាំងសម្ងាត់ដែលផុតកំណត់។

47,4% នៃសំណើត្រូវបានធ្វើឡើងបន្ទាប់ពីកំណត់ត្រាដែលមានស្រាប់បានផុតកំណត់។ នេះគឺខ្ពស់មិនសមហេតុផល។

តើ​នឹង​មាន​ឥទ្ធិពល​អ្វី​ទៅ​លើ​ឃ្លាំង​សម្ងាត់ ប្រសិនបើ TTL អប្បបរមា​ត្រូវ​បាន​កំណត់?

អ័ក្ស X គឺជាតម្លៃ TTL អប្បបរមា។ កំណត់ត្រាដែលមានប្រភព TTL លើសពីតម្លៃនេះមិនត្រូវបានប៉ះពាល់ទេ។

អ័ក្ស Y គឺជាភាគរយនៃសំណើពីអតិថិជនដែលមានធាតុនៅក្នុងឃ្លាំងសម្ងាត់រួចហើយ ប៉ុន្តែវាបានផុតកំណត់ហើយកំពុងធ្វើការស្នើសុំថ្មី។

ចំណែកនៃសំណើ "បន្ថែម" ត្រូវបានកាត់បន្ថយពី 47% ទៅ 36% ដោយគ្រាន់តែកំណត់ TTL អប្បបរមាដល់ 5 នាទី។ តាមរយៈការកំណត់ TTL អប្បបរមាដល់ 15 នាទី ចំនួននៃសំណើទាំងនេះធ្លាក់ចុះដល់ 29% ។ TTL អប្បបរមា 1 ម៉ោងកាត់បន្ថយពួកគេមកត្រឹម 17% ។ ខុសគ្នាខ្លាំង!

តើធ្វើដូចម្តេចអំពីការមិនផ្លាស់ប្តូរអ្វីនៅលើផ្នែកម៉ាស៊ីនមេ ប៉ុន្តែជំនួសឱ្យការកំណត់ TTL អប្បបរមានៅក្នុងឃ្លាំងសម្ងាត់ DNS របស់អតិថិជន (រ៉ោតទ័រ អ្នកដោះស្រាយមូលដ្ឋាន)?

ចំនួននៃសំណើដែលតម្រូវឱ្យធ្លាក់ចុះពី 47% ទៅ 34% ជាមួយនឹង TTL អប្បបរមា 5 នាទី ទៅ 25% ជាមួយនឹងអប្បបរមា 15 នាទី និងដល់ 13% ជាមួយនឹងអប្បបរមា 1 ម៉ោង។ ប្រហែលជា 40 នាទីគឺល្អបំផុត។

ឥទ្ធិពលនៃការផ្លាស់ប្តូរតូចមួយនេះគឺធំធេងណាស់។

តើមានផលវិបាកអ្វីខ្លះ?

ជាការពិតណាស់ សេវាកម្មនេះអាចត្រូវបានផ្លាស់ទីទៅអ្នកផ្តល់សេវាពពកថ្មី ម៉ាស៊ីនមេថ្មី បណ្តាញថ្មី ដែលតម្រូវឱ្យអតិថិជនប្រើកំណត់ត្រា DNS ចុងក្រោយបំផុត។ ហើយ TTL តូចល្មមជួយធ្វើការផ្លាស់ប្តូរបែបនេះដោយរលូន និងមិនអាចយល់បាន។ ប៉ុន្តែជាមួយនឹងការផ្លាស់ប្តូរទៅកាន់ហេដ្ឋារចនាសម្ព័ន្ធថ្មី គ្មាននរណាម្នាក់រំពឹងថាអតិថិជននឹងផ្លាស់ប្តូរទៅកាន់កំណត់ត្រា DNS ថ្មីក្នុងរយៈពេល 1 នាទី 5 នាទី ឬ 15 នាទីនោះទេ។ ការកំណត់ TTL អប្បបរមាដល់ 40 នាទីជំនួសឱ្យ 5 នាទីនឹងមិនរារាំងអ្នកប្រើប្រាស់ពីការចូលប្រើសេវាកម្មនោះទេ។

ទោះជាយ៉ាងណាក៏ដោយ វានឹងកាត់បន្ថយភាពយឺតយ៉ាវយ៉ាងខ្លាំង និងធ្វើអោយប្រសើរឡើងនូវភាពឯកជន និងភាពជឿជាក់ ដោយជៀសវាងការស្នើសុំដែលមិនចាំបាច់។

ជាការពិតណាស់ RFCs និយាយថា TTL ត្រូវតែអនុវត្តតាមយ៉ាងតឹងរ៉ឹង។ ប៉ុន្តែការពិតគឺថាប្រព័ន្ធ DNS បានក្លាយទៅជាគ្មានប្រសិទ្ធភាព។

ប្រសិនបើអ្នកកំពុងធ្វើការជាមួយម៉ាស៊ីនមេ DNS ដែលមានការអនុញ្ញាត សូមពិនិត្យមើល TTLs របស់អ្នក។ តើអ្នកពិតជាត្រូវការតម្លៃទាបគួរឱ្យអស់សំណើចបែបនេះមែនទេ?

ជាការពិតណាស់មានហេតុផលល្អដើម្បីកំណត់ TTLs តូចៗសម្រាប់កំណត់ត្រា DNS ។ ប៉ុន្តែមិនមែនសម្រាប់ 75% នៃចរាចរ DNS ដែលនៅតែមិនផ្លាស់ប្តូរ។

ហើយប្រសិនបើសម្រាប់ហេតុផលមួយចំនួន អ្នកពិតជាត្រូវប្រើ TTLs ទាបសម្រាប់ DNS ក្នុងពេលតែមួយ ត្រូវប្រាកដថាគេហទំព័ររបស់អ្នកមិនមានការបើកឃ្លាំងសម្ងាត់ទេ។ សម្រាប់ហេតុផលដូចគ្នា។

ប្រសិនបើអ្នកមានឃ្លាំងសម្ងាត់ DNS មូលដ្ឋានដែលកំពុងដំណើរការ ដូចជា dnscrypt-ប្រូកស៊ីដែលអនុញ្ញាតឱ្យអ្នកកំណត់ TTLs អប្បបរមា សូមប្រើមុខងារនេះ។ នេះល្អណាស់។ គ្មានអ្វីអាក្រក់នឹងកើតឡើងទេ។ កំណត់ TTL អប្បបរមាទៅប្រហែល 40 នាទី (2400 វិនាទី) និង 1 ម៉ោង។ ជួរសមហេតុផលណាស់។

ប្រភព: www.habr.com