DNS-resolverlochboeken fersus VPN-ferbiningslochboeken: wat elk befettet

In DNS-resolverlochboek en in VPN-ferbiningslochboek binne beide netwurkregistraasjes, beide nuttich en net útwikselber. De resolver ûntfangt nammen dêr't er om frege waard om te beantsjen. It VPN-einpunt behannelet tunnelferbiningen en registrearret wat syn ymplemintaasje keas om dêroer fêst te lizzen. Se kinne yn itselde gebou wêze, troch itselde team betsjinne wurde en ûnder deselde privacyferklearring falle, en dochs beskriuwe se ferskillende barrens mei ferskillende identifikatoaren en ferskillend bewar. It iene lêze as wie it it oare, is hoe't ûndersiken misrinne.

Twa lochboeken, twa barrens

In resolverynskriuwing beantwurdet in fraach oer nammejouwing: dizze klant frege op dit stuit om dizze namme, en it antwurd wie dit. In VPN-ynskriuwing beantwurdet in fraach oer ferbining: dizze peer ferfêstige of ferlear in tunnel, krige dit adres tawiisd, en ferfierde sawat safolle gegevens foar't er fuort gie. Gjin fan beide is in registraasje fan wat de brûker binnen in HTTPS-sesje die, en gjin fan beide ferfangt de oare.

It ûnderskie hat in praktysk gefolch foar beloften. In útspraak dat in VPN-oanbieder gjin tunnelaktiviteit registrearret, seit neat oer de resolver dy't er útjout, en it bewarpolicy fan in resolver seit neat oer wa't him oan de tunnel ferbûn. Elk bewearing heart by syn eigen operator en syn eigen systeem.

Folgje de fraach foar't jo ien fan beide lochboeken lêze

In fraach berikt in resolver allinnich as it paad him echt freget. In applikaasje kin de resolver fan it bestjoeringssysteem brûke, syn eigen fersiferle DNS-klant draaie, of in antwurd út 'e buffer lêze en nea wat stjoere. Dat in resolverlochboek dat neat showt is gjin bewiis dat in namme nea brûkt is; it is bewiis dat dizze resolver net frege is.

resolvectl status
dig @127.0.0.53 build.corp.example +qr
journalctl -u systemd-resolved -n 20 --no-pager

Dy lêste opdracht lêst it eigen deiboek fan 'e lokale resolver, wat net itselde is as it lochboek fan 'e boppesteande tsjinner. As jo fragen fia DNS over HTTPS by in oanbieder wei gean, kin de lokale stub neat sjen litte wylst de oanbieder de folsleine registraasje hat, en de oanbieder is in oare operator mei in oar policy.

Wat elk registraasje sjen kin en net sjen kin

Se oaninoar keppelje is it echte wurk, en se oaninoar keppelje is net altyd mooglik. In resolver dy't klantadressen registrearret kin ferlike wurde mei in VPN dy't adressen út in bekend pool tawiist, en dy ferliking jout in leauwensweardige keppeling tusken in frege namme en in tunnel, dy't in keppeling tusken twa registraasjes bliuwt en gjin registraasje fan in persoan.

Fersiferle DNS feroaret it ferfier, net de sichtberens by it einpunt. De resolver ûntfangt noch altyd de fraach dy't er beantwurdet, sa't RFC 8484 dúdlik makket, en bewar by dy resolver is in policybeslút en net in eigenskip fan it protokol.

Wêr't splitst DNS en buffers it ferhaal yn 'e war bringe

Mear resolvers is normaal. In split-DNS-ûntwerp stjoert ynterne nammen nei in ynterne tsjinner en al it oare nei in iepenbiere, dus ien ûndersyk kin twa lochboeken omfetsje dy't nea bedoeld wiene om kombinearre te wurden en twa bewarynstellings dy't nea bedoeld wiene om ferlike te wurden. Fraqen by beide sjen is bewiis dat it ûntwerp wurket, gjin bewiis fan in lek.

Buffers snije de oare kant út. In populêre namme kin oerenlang út 'e buffer beantwurde wurde, dus it registraasje fan 'e resolver showt de earste fraach en dêrnei neat, wylst de applikaasje fan 'e brûker deselde namme bliid trochgiet mei oplossen. It ûntbrekken fan ynskriuwingen nei in beskaat momint betsjut net dat nimmen de namme nei dat momint brûkt hat.

Eftergrûnferkear is de tredde ferfoarming. In telefoan dy't by it opstarten in telemetrienamme oplost, in browser dy't in domein foar sykfoarstel oplost, en in fernijer dy't elk oere kontakt siket, ferskine allegear yn in resolverlochboek njonken de namme dy't jo echt wichtich fine. Folume yn dat lochboek is gjin oandacht, en fragen telle is gjin besiten telle. In resolverlochboek is in registraasje fan fragen, en fragen binne goedkeap te meitsjen.

Stel de bewarfragen apart

Stel foar elk systeem trije fragen: wa sammelt, wat wurdt sammele, en hoelang't it bewarre wurdt. Freegje dan wa't it lêze kin en ûnder hokker proses. De RFC 8484-besprekking fan DNS over HTTPS is in goede herinnering dat fersiferle ferfier it einpunt net fuorthellet, en de eigen dokumintaasje fan in operator is de iennige betroubere útspraak oer wat dat einpunt bewarret.

As der in bewearing oer privacy dien wurdt oer “de VPN”, spjalt dy dan yn ûnderdielen foar't jo him oannimme: de tunneloperator, de resolver dy't de tunnel útjout, elke boppesteande resolver dy't dy fragen berikke, en de applikaasjes op it apparaat. Elk hat syn eigen antwurd, en in bewearing dy't foar ien krekt is, wurdt gauris werhelle as soe er alle fjouwer dekke.

Brûk foar it oplossen fan problemen deselde splitsing. Freegje hokker applikaasje de fraach die en hokker resolver him beantworte, en sjoch dan yn it lochboek dat dy barren echt besit. Rieden út it oare lochboek sparret in minút en kostet in middei.