Mae hwyrni DNS isel yn allweddol i bori rhyngrwyd cyflym. Er mwyn ei leihau, mae'n bwysig dewis gweinyddwyr DNS yn ofalus a . Ond y cam cyntaf yw cael gwared ar ymholiadau diwerth.
Dyna pam y dyluniwyd DNS yn wreiddiol fel protocol hynod cacheable. Mae gweinyddwyr parth yn gosod amser i fyw (TTL) ar gyfer cofnodion unigol, ac mae datryswyr yn defnyddio'r wybodaeth hon wrth storio cofnodion yn y cof i osgoi traffig diangen.
A yw caching yn effeithiol? Ychydig flynyddoedd yn Γ΄l, dangosodd fy ymchwil bach nad oedd yn berffaith. Gadewch i ni edrych ar y sefyllfa bresennol.
I gasglu gwybodaeth fe wnes i glytio i arbed y gwerth TTL ar gyfer yr ymateb. Fe'i diffinnir fel TTL lleiaf ei gofnodion ar gyfer pob cais sy'n dod i mewn. Mae hyn yn rhoi trosolwg da o ddosbarthiad TTL traffig go iawn, ac mae hefyd yn ystyried poblogrwydd ceisiadau unigol. Bu'r fersiwn glytiog o'r gweinydd yn gweithio am sawl awr.
Mae'r set ddata canlyniadol yn cynnwys 1 o gofnodion (enw, qtype, TTL, stamp amser). Dyma'r dosbarthiad TTL cyffredinol (echel X yw TTL mewn eiliadau):
Ar wahΓ’n i ergyd fach yn 86 (yn bennaf ar gyfer cofnodion SOA), mae'n eithaf amlwg bod y TTLs yn yr ystod isel. Gadewch i ni edrych yn agosach:
Iawn, nid yw TTLs mwy nag 1 awr yn ystadegol arwyddocaol. Yna gadewch i ni ganolbwyntio ar yr ystod 0β3600:
Mae'r rhan fwyaf o TTLs rhwng 0 a 15 munud:
Mae'r mwyafrif helaeth rhwng 0 a 5 munud:
Nid yw'n dda iawn.
Mae dosbarthiad cronnol yn gwneud y broblem hyd yn oed yn fwy amlwg:
Mae gan hanner yr ymatebion DNS TTL o 1 munud neu lai, ac mae gan dri chwarter TTL o 5 munud neu lai.
Ond arhoswch, mae'n waeth mewn gwirionedd. Wedi'r cyfan, dyma TTL gan weinyddion awdurdodol. Fodd bynnag, mae datryswyr cleientiaid (e.e. llwybryddion, caches lleol) yn derbyn TTL gan ddatryswyr i fyny'r afon, ac mae'n gostwng bob eiliad.
Felly gall y cleient ddefnyddio pob cofnod, ar gyfartaledd, ar gyfer hanner y TTL gwreiddiol cyn anfon cais newydd.
Efallai mai dim ond i geisiadau anarferol y mae'r TTLs isel iawn hyn yn berthnasol ac nid i wefannau ac APIs poblogaidd? Gadewch i ni gael golwg:
Echel X yw TTL ac echel Y yw poblogrwydd ymholiad.
Yn anffodus, yr ymholiadau mwyaf poblogaidd hefyd yw'r rhai gwaethaf i'w storio.
Gadewch i ni chwyddo i mewn:
Rheithfarn: mae'n ddrwg iawn. Roedd eisoes yn ddrwg o'r blaen, ond aeth yn waeth byth. Mae caching DNS wedi dod bron yn ddiwerth. Wrth i lai o bobl ddefnyddio datrysiad DNS eu ISP (am resymau da), daw'r cynnydd mewn hwyrni yn fwy amlwg.
Mae caching DNS wedi dod yn ddefnyddiol yn unig ar gyfer cynnwys nad oes neb yn ymweld ag ef.
Sylwch hefyd y gall y meddalwedd dehongli TTLs isel.
Pam felly
Pam mae cofnodion DNS wedi'u gosod i TTL mor isel?
- Gadawyd balanswyr llwyth etifeddiaeth gyda gosodiadau diofyn.
- Mae yna fythau bod cydbwyso llwyth DNS yn dibynnu ar TTL (nid yw hyn yn wir - ers dyddiau Netscape Navigator, mae cleientiaid wedi dewis cyfeiriad IP ar hap o set o RRs ac wedi rhoi cynnig arall yn dryloyw os na allant gysylltu)
- Mae gweinyddwyr am wneud newidiadau ar unwaith, felly mae'n haws cynllunio.
- Mae gweinyddwr gweinydd DNS neu gydbwysedd llwyth yn gweld ei dasg fel un sy'n defnyddio'r ffurfweddiad y mae defnyddwyr yn gofyn amdano yn effeithlon, ac nid yn cyflymu gwefannau a gwasanaethau.
- Mae TTLs isel yn rhoi tawelwch meddwl i chi.
- I ddechrau, mae pobl yn gosod TTLs isel i'w profi ac yna'n anghofio eu newid.
Wnes i ddim cynnwys "methiant" yn y rhestr oherwydd mae'n dod yn llai a llai perthnasol. Os oes angen i chi ailgyfeirio defnyddwyr i rwydwaith arall dim ond i arddangos tudalen gwall pan fydd popeth arall wedi'i dorri, mae'n debyg y bydd oedi o fwy nag 1 munud yn dderbyniol.
Yn ogystal, mae TTL un munud yn golygu, os yw gweinyddwyr DNS awdurdodol yn cael eu rhwystro am fwy nag 1 munud, ni fydd unrhyw un arall yn gallu cyrchu gwasanaethau dibynnol. Ac ni fydd dileu swydd yn helpu os mai gwall cyfluniad neu hac yw'r achos. Ar y llaw arall, gyda TTLs rhesymol, bydd llawer o gleientiaid yn parhau i ddefnyddio'r cyfluniad blaenorol a byth yn sylwi ar unrhyw beth.
Gwasanaethau CDN a balanswyr llwyth sydd ar fai i raddau helaeth am TTLs isel, yn enwedig pan fyddant yn cyfuno CNAMEs Γ’ TTLs isel a chofnodion Γ’ TTLs yr un mor isel (ond annibynnol):
$ 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
Pryd bynnag y daw'r cofnodion CNAME neu unrhyw un o gofnodion A i ben, rhaid anfon cais newydd. Mae gan y ddau TTL 30 eiliad, ond nid yw yr un peth. Y TTL cyfartalog gwirioneddol fydd 15 eiliad.
Ond arhoswch! Mae hyd yn oed yn waeth. Mae rhai datryswyr yn ymddwyn yn wael iawn yn y sefyllfa hon gyda dau TTL isel cysylltiedig:
$dril raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 YN CNAME github.map.fastly.net. github.map.fastly.net . 1 YN A 151.101.16.133
Mae'n debyg bod y datryswr Level3 yn rhedeg ar BIND. Os byddwch yn parhau i anfon y cais hwn, bydd TTL o 1 bob amser yn cael ei ddychwelyd. Yn y bΓ΄n, raw.githubusercontent.com byth yn cached.
Dyma enghraifft arall o sefyllfa o'r fath gyda pharth poblogaidd iawn:
$ 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
O leiaf tri chofnod CNAME. Ay. Mae gan un TTL gweddus, ond mae'n gwbl ddiwerth. Mae gan CNAMEs eraill TTL cychwynnol o 60 eiliad, ond ar gyfer parthau akamai.net yr uchafswm TTL yw 20 eiliad ac nid oes yr un ohonynt mewn cyfnod.
Beth am barthau sy'n pleidleisio dyfeisiau Apple yn gyson?
$ 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
Bydd yr un broblem Γ’ Firefox a TTL yn sownd ar 1 eiliad y rhan fwyaf o'r amser wrth ddefnyddio Datrysydd Lefel 3.
Dropbox?
$ dril client.dropbox.com @8.8.8.8 client.dropbox.com. 7 YN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 YN A 162.125.67.3 $ dril client.dropbox.com @4.2.2.2 client.dropbox.com. 1 YN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 YN A 162.125.64.3
Wrth y recordiad safebrowsing.googleapis.com Gwerth TTL yw 60 eiliad, fel parthau Facebook. Ac, unwaith eto, o safbwynt y cleient, mae'r gwerthoedd hyn yn cael eu haneru.
Beth am osod isafswm TTL?
Gan ddefnyddio'r enw, math o gais, TTL, a stamp amser a storiwyd yn wreiddiol, ysgrifennais sgript i efelychu 1,5 miliwn o geisiadau yn mynd trwy ddatryswr caching i amcangyfrif nifer y ceisiadau diangen a anfonwyd oherwydd cofnod cache a ddaeth i ben.
Gwnaed 47,4% o geisiadau ar Γ΄l i gofnod presennol ddod i ben. Mae hyn yn afresymol o uchel.
Beth fydd yr effaith ar gelcio os gosodir yr isafswm TTL?
Yr echel X yw'r isafswm gwerthoedd TTL. Ni effeithir ar gofnodion sydd Γ’ ffynhonnell TTL uwchlaw'r gwerth hwn.
Yr echel Y yw canran y ceisiadau gan gleient sydd eisoes Γ’ chofnod wedi'i storio, ond mae wedi dod i ben ac yn gwneud cais newydd.
Gostyngir cyfran y ceisiadau βychwanegolβ o 47% i 36% trwy osod yr isafswm TTL i 5 munud. Drwy osod yr isafswm TTL i 15 munud, mae nifer y ceisiadau hyn yn gostwng i 29%. Mae isafswm TTL o 1 awr yn eu lleihau i 17%. Gwahaniaeth sylweddol!
Beth am beidio Γ’ newid unrhyw beth ar ochr y gweinydd, ond yn lle hynny gosod y TTL lleiaf yn caches DNS cleient (llwybryddion, datryswyr lleol)?
Mae nifer y ceisiadau sydd eu hangen yn disgyn o 47% i 34% gydag isafswm TTL o 5 munud, i 25% gydag isafswm o 15 munud, ac i 13% gydag isafswm o 1 awr. Efallai mai 40 munud yw'r gorau posibl.
Mae effaith y newid bach hwn yn enfawr.
Beth yw'r canlyniadau?
Wrth gwrs, gellir symud y gwasanaeth i ddarparwr cwmwl newydd, gweinydd newydd, rhwydwaith newydd, sy'n ei gwneud yn ofynnol i gleientiaid ddefnyddio'r cofnodion DNS diweddaraf. Ac mae TTL gweddol fach yn helpu i wneud trawsnewidiad o'r fath yn llyfn ac yn ddirybudd. Ond gyda'r newid i seilwaith newydd, nid oes neb yn disgwyl i gleientiaid ymfudo i gofnodion DNS newydd o fewn 1 munud, 5 munud, neu 15 munud. Ni fydd gosod yr isafswm TTL i 40 munud yn lle 5 munud yn atal defnyddwyr rhag cyrchu'r gwasanaeth.
Fodd bynnag, bydd hyn yn lleihau hwyrni yn sylweddol ac yn gwella preifatrwydd a dibynadwyedd trwy osgoi ceisiadau diangen.
Wrth gwrs, mae'r RFCs yn dweud bod yn rhaid dilyn TTL yn llym. Ond y gwir amdani yw bod y system DNS wedi dod yn rhy aneffeithlon.
Os ydych chi'n gweithio gyda gweinyddwyr DNS awdurdodol, gwiriwch eich TTLs. Oes gwir angen gwerthoedd mor chwerthinllyd o isel arnoch chi?
Wrth gwrs, mae yna resymau da dros osod TTLs bach ar gyfer cofnodion DNS. Ond nid ar gyfer y 75% o draffig DNS sy'n aros bron yn ddigyfnewid.
Ac os am ryw reswm mae gwir angen i chi ddefnyddio TTLs isel ar gyfer DNS, ar yr un pryd gwnewch yn siΕ΅r nad oes gan eich gwefan caching galluogi. Am yr un rhesymau.
Os oes gennych storfa DNS lleol yn rhedeg, fel sy'n eich galluogi i osod isafswm TTL, defnyddiwch y swyddogaeth hon. Mae hyn yn iawn. Ni fydd dim byd drwg yn digwydd. Gosodwch y TTL lleiaf i tua 40 munud (2400 eiliad) ac 1 awr. Ystod eithaf rhesymol.
Ffynhonnell: hab.com