DNS humilis latency clavis est ad pascendum penitus ieiunium. Ad eam obscuram pertinet, DNS servientes diligenter eligere et . Sed primus gradus est ad tollendum inutiles inquisitiones.
Quam ob rem DNS principio designatum est ut protocollum cacheabile. Zona administratores tempus vivendi (TTL) singulis visceribus constituerunt, et resolutores hac informatione utuntur cum viscus in memoria accommodandi ad mercaturam necessariam vitandam.
Caching efficax est? A duobus abhinc annis, mea investigatio parum ostendit quod non erat perfectus. Videamus praesentem rerum statum.
Ut notitias perantiqua ut salvum ttl valorem pro responsione. Definitur ut minimum TTL tabularum suarum pro singulis postulationibus advenientis. Hoc bonum dat prospectum TTL distributionis negotiationis verae, et etiam considerat favorem singularum petitionum. Versio perantiqua servientis per aliquot horas laboravit.
Proventus notitia copia constat ex 1 monumentis (nomen, qtype, TTL, indicatione). Hic est altiore TTL distributio (X-axis TTL in secundis);
Extra gibba minoris ad 86 (plerumque pro SOA commentariis), satis clarum est TTLs in iugi humili esse. Propius inspice:
Bene, TTLs maior quam hora 1 peraeque signantia non sunt. Tunc dolor sit amet in range 0-3600:
Maxime TTLs sunt ab 0 ad XV minuta:
Maior pars maxima ab 0 ad 5 minuta sunt:
Etiam non ipsum.
Cumulativa distributio quaestionem etiam manifestiorem facit;
Dimidium DNS responsionum habent TTL de 1 minutis minusve, et tres quadrantes TTL pro 5 minutis vel minus habent.
Sed expecta, peius est. Post omnes, hoc est TTL ab auctoritative ministrantibus. Sed clientes resolventes (e.g. iter, caches locales) TTL ex flumine resolventes accipiunt, et secundo minuuntur.
Ita client uti potest actu quolibet introitu pro, in mediocris, dimidia parte originali TTL antequam novam petitionem mittat.
Fortasse haec TTLs nimis humilis solum ad inusitatas petitiones pertinet et non in websites popularibus et APIs? Videamus lets:
X axis TTL et Y axis quaesita est popularis.
Infeliciter, populares quaesitiones etiam pessimae sunt ad thesaurum.
Zoom lets in:
Iudicium: vere malum est. Iam malum erat, sed peius erat. DNS caching paene inutilis facta est. Cum pauciores homines DNS resolventis ISP utantur (ob causas bonas), incrementum latency magis notabile fit.
DNS caching utilis factus est tantum contentus quod nemo visitat.
Etiam nota ut luctus interpretantur humilis TTLs.
Quid ita?
Cur DNS monumenta tam humili ttl?
- Legatum onus libratores relicti sunt per default occasus.
- Fabulae sunt quae DNS onus librationis ex TTL pendent (quod verum non est - cum dies Navigatoris Netscape, clientes temere IP inscriptionem elegerunt ex statuto RRs et luculenter aliam si coniungere non possunt)
- Magistratus volunt statim mutationes adhibere, ut facilius est consilium.
- Administrator servientis vel oneris libratoris videt suum munus tam efficaciter explicandi configurationem quam petentibus utentibus, et locis et officiis non accelerandis.
- Humilis TTLs det tibi tranquillitatem mentis.
- Homines initio TTLs humiliaverunt ad probationem et tunc obliviscuntur eos mutare.
"Defectum" in indice non comprehendi quia minus ac minus convenit. Si usores ad aliam retis redirigere debes tantum errorem ostendere pagina cum omnino omnia alia franguntur, mora plus quam 1 minutorum probabilis est probabilis.
Accedit unum minutum TTL significat quod, si DNS auctoritative servientibus plus quam 1 minutis interclusus est, nemo alius officia dependens accedere poterit. Et redundantia non adiuvabit si causa est conformatio erroris vel hack. Contra, cum rationabili TTLs, multi clientes in priore configuratione uti perseverent nec quidquam animadvertunt.
CDN officia et libratores onerant late culpas demissas TTLs, praesertim cum CNAMEs cum humilibus TTLs et monumentis coniungunt cum aequalibus (sed independentibus) 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
Quoties CNAME vel aliqui ex monumentis pereunt, nova postulatio mittenda est. 30 Alter ttl alter ambos habent, sed non est idem. Mediocris ipsa TTL secunda XV erit.
Sed expecta! Est etiam asperiores. Nonnulli resolventes pessime se gerunt in hoc statu cum duobus humilibus adiunctis TTLs;
raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
The Level3 resolver probably runs on BIND. Si pergas hanc petitionem mittere, semper TTL of 1 reddatur. raw.githubusercontent.com numquam enim conditivo.
Alterum exemplum huius rei cum admodum populari ditione est:
$ 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 tres saltem tabulas. Immo vero. Unus honestus est TTL, sed omnino inutilis est. Aliae CNAMEs initialem TTL secundis 60 secundis habent, sed pro ditionibus akamai.net maximum TTL est XX secundis et nulla eorum in phase.
Quid de dominiis quae continenter machinas Apple tondere?
$ 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
Eadem problema cum Firefox et TTL in secundo potissimum tempore adhæsit cum solvendo Level1 utens.
Dropbox?
client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
In memoria safebrowsing.googleapis.com TTL valor 60 secundus, sicut Facebook ditionibus. Et rursus ex huius consideratione valores isti dimidiati sunt.
Quid de occasu minimum TTL?
Nomen, petitio generis, TTL, et initio indicatione temporis condita, scripseram ut simulare 1,5 decies centena petitiones pertranseuntes per solutionem solutionis ad aestimandum volumen petitionum supervacuarum propter ingressum cache exspirasse.
47,4% petitiones factae sunt postquam recordum existens expiravit. Hoc est sine ratione altum.
Quid erit impetus in caching si minimum TTL positum est?
Axis X est valorum minimorum TTL. Tabulae cum fonte TTLs supra hunc valorem non afficiuntur.
Axis Y recipis petitionum clientis iam habet ingressum conditivo, sed expiravit et novam petitionem facit.
Partes petitionum "extrae" reducuntur ab 47% ad 36%, si minimum TTL ad 5 minuta ponas. Ponendo minimum TTL ad 15 minuta, numerus harum petitionum ad 29% recedit. Minima TTL horae 1 reducit eas ad 17%. Differentia notabilis!
Quomodo nihil mutandum in calculonis servi, sed pro minimum TTL in cliens DNS cella disponens (iteri, resolventes locales)?
Numerus petitionum destillat ab 47% ad 34% cum minimum TTL 5 minutarum, ad 25% cum minimum 15 minutorum, et ad 13% cum minima 1 horae. Fortasse XL minuta optimal est.
Ictus huius parvae mutationis immensus est.
Quid consequentia?
Utique, ministerium moveri potest ad novam nubem provisoris, novi servientis, retis novae, clientes postulantes ut recentissimis DNS monumentis utantur. Et satis parva TTL adiuvat ad talem transitum leniter et sine sensu. Sed transitu ad novas infrastructuras, nemo clientes expectat ut ad novas DNS monumenta transmigrent intra 1 minuta, 5 minuta, vel 15 minuta. Proponere minimum TTL ad 40 minuta loco 5 minuta non prohibebit utentes ab accessu servitii.
Hoc tamen significanter latentiam minuet et intimitatem ac fidem emendabit, superfluas postulationes vitando.
Nempe RFCs dicunt TTL stricte sequendum esse. Sed veritas est quod DNS ratio nimis inutilis facta est.
Si cum auctoritative DNS servientibus laboras, TTLs tuos quaeso reprime. Itane ridicule opus est vilioribus valoribus?
Scilicet, bonae causae sunt parvae TTLs pro DNS monumentis. Sed non pro 75% DNS negotiationis quod virtualiter immutatum manet.
Et si aliqua de causa pro DNS TTLs humilitatis uti debes, simul fac ut situs tuus non habeat capacitatem caching. Eadem de causa.
Si DNS cella currens localis habes, ut quod permittit tibi ut minimum ponas TTLs, hoc munere utere. Hoc est pulchrum. Nihil mali fiet. Pone minimum TTL ad circiter 40 minuta (2400 secunda) et 1 hora. Rationabile satis patens.
Source: www.habr.com