Inleiding
In dit document wordt beschreven hoe OpenDNS/Umbrella cachebronrecords herstelt.
Overzicht
De OpenDNS/Umbrella resolvers gebruiken een programma dat bekend staat als OpenDNSCache (ODC) om DNS-query's op te lossen. ODC cachet gegevens die het ontvangt om sneller en efficiënter resultaten aan klanten te retourneren. Dit artikel gaat in op hoe caching plaatsvindt en wanneer het wordt gebruikt.
Dit artikel is bedoeld voor gebruikers die meer willen weten over de specifieke kenmerken van ODC-caching (meestal nameserver- en domeinbeheerders), of voor gevallen waarin DNS-resolutie mogelijk niet werkt zoals verwacht.
Welke gegevens worden in de cache opgeslagen?
Volgens RFC 2181 (https://datatracker.ietf.org/doc/html/rfc2181) kunnen antwoorden worden teruggestuurd in een antwoord of worden opgeslagen in een cache op basis van de betrouwbaarheid van de gegevens. De RFC definieert 7 vertrouwensniveaus in paragraaf 5.4.1:
- Gegevens uit een primaire-zonebestand, anders dan lijmgegevens.
- Dit geldt alleen voor gezaghebbende nameservers, niet voor de OpenDNS-resolvers
- Gegevens van een zone-overdracht, met uitzondering van lijm.
- Dit geldt alleen voor gezaghebbende nameservers, niet voor de OpenDNS-resolvers
- De gezaghebbende gegevens die zijn opgenomen in het antwoordgedeelte van een gezaghebbend antwoord.
- Dit geldt voor OpenDNSCache
- Gegevens uit het autoriteitsgedeelte van een gezaghebbend antwoord.
- Dit geldt voor OpenDNSCache
- Lijm uit een primaire zone of lijm uit een zone-overdracht.
- Dit geldt alleen voor gezaghebbende nameservers, niet voor de OpenDNS-resolvers
- i) Gegevens uit het antwoordgedeelte van een niet-gezaghebbend antwoord, en ii) niet-gezaghebbende gegevens uit het antwoordgedeelte van gezaghebbende antwoorden.
- i) is een voorbeeld van wat onze oplossers terug te keren. Niet-gezaghebbende gegevens.
- Voor ii), merk op dat het antwoordgedeelte van een gezaghebbend antwoord normaal gesproken alleen gezaghebbende gegevens bevat. Wanneer de gezochte naam echter een alias is (zie paragraaf 10.1.1), is alleen het record dat die alias beschrijft noodzakelijk gezaghebbend. Cliënten kunnen ervan uitgaan dat andere records afkomstig moeten zijn uit de cache van de server. Wanneer gezaghebbende antwoorden vereist zijn, kan de klant opnieuw vragen, met behulp van de canonieke naam die aan het alias is gekoppeld.
- i) Aanvullende informatie uit een gezaghebbend antwoord; ii) Gegevens uit het autoriteitsgedeelte van een niet-gezaghebbend antwoord; iii) Aanvullende informatie uit niet-gezaghebbende antwoorden.
- Dit alles geldt voor OpenDNSCache
- Records ontvangen van een van deze bronnen mogen niet in de cache worden opgeslagen om de resultaten terug te sturen naar zoekopdrachten.
OpenDNSCache cachet gegevens van antwoorden met de vertrouwensniveaus 3, 4 en 6. Als we nieuwe gegevens ontvangen die een beter of gelijk vertrouwensniveau hebben, vervangen we de oude cachevermelding.
De uitzondering hier is voor NS-records, waarvoor we alleen gegevens vervangen door een beter vertrouwensniveau.
Hoe worden gegevens toegevoegd en verwijderd uit de cache?
Verlopen gegevens worden niet uit de cache verwijderd. Dit is de basis van de SmartCache-functie, waarbij we verlopen bronrecords (RR's) uit de cache retourneren als we om de een of andere reden de autoriteiten niet kunnen bereiken.
In plaats daarvan is de cache op elke resolver een vaste grootte en wanneer een nieuwe RR aan de cache wordt toegevoegd, wordt de oudste RR verwijderd. Dit kan worden gevisualiseerd als een wachtrij waar nieuwe items worden toegevoegd aan de wachtrij, waardoor oude items uit de wachtrij worden gestoten (voor de computerwetenschappers die er zijn, wordt dit eigenlijk geïmplementeerd als een cirkelvormige dubbelgekoppelde lijst).
Merk op dat, zoals hierboven beschreven, een DNS-reactie meerdere RR's kan bevatten die verschillende vertrouwensniveaus hebben, niet allemaal de gegevens die oorspronkelijk zijn aangevraagd. Dus, na het ontvangen van een reactie, kunnen we meerdere RR's toevoegen aan de cache.
Zoals hierboven vermeld, zijn NS-records vrijgesteld van dit gedrag, omdat we alleen vermeldingen voor NS-records in de cache vervangen als het vertrouwensniveau van de gegevens hoger is dan het bestaande item. Dit wordt gedaan om ervoor te zorgen dat we veranderingen in de ouderlijm kunnen detecteren als de oude autoriteiten nog steeds reageren en zichzelf als autoriteit teruggeven.
Feedback