Is het valsheid in geschrifte om andermans TTL aan te passen?

| AE 9960 | Cloud, Domeinnamen | 10 reacties

Sorry, beetje nerdtitel. Via Twitter de vraag:

DNS TTL violations is a controversial topic. It basically means a resolver overrides a TTL value provided by an authoritative server, and then serving its clients with this value. In this post, we analyse if this is happening in the wild. … is ttl violation geen valsheid in geschrifte?

Nu zie ik wel vaker de discussie of het aanpassen van elektronische informatie telt als valsheid in geschrifte, dus laten we er weer eens voor gaan zitten. In de basis is het wetsartikel vrij simpel:

Hij die een geschrift dat bestemd is om tot bewijs van enig feit te dienen, valselijk opmaakt of vervalst, met het oogmerk om het als echt en onvervalst te gebruiken of door anderen te doen gebruiken, wordt als schuldig aan valsheid in geschrift gestraft, met gevangenisstraf van ten hoogste zes jaren of geldboete van de vijfde categorie.

Het moet dus gaan om een geschrift. Dit mag ook elektronisch zijn, dus een digitaal document of gegevensverzameling valt er ook onder. Het geschrift moet wel een bewijsfunctie hebben, het doel van het geschrift moet zijn dat je er iets mee kunt aantonen of weerleggen. Een bioscoopkaartje voldoet aan die discussie (het bewijst dat je naar die en die film mag), een liefdesbrief niet (en nee “het bewijst je liefde” is juridisch niet goed genoeg). In de elektronische wereld zou een nep-SSL-certificaat bijvoorbeeld deze functie hebben, maar nepnieuws niet.

Dat “valselijk opmaken of vervalsen” is een brede omschrijving voor de ‘valsheid’ die je pleegt: je past dingen aan in een echt bewijsdocument, of je maakt een geheel nieuw document dat eruit ziet als echt. Beiden zijn goed genoeg om van valsheid in geschrifte te plegen. Wel is daarbij vereist dat het doel van je aanpassing is dat je het resultaat voor echt wilt laten doorgaan. Een bioscoopkaartje met Photoshop bewerken tot een ludieke uitnodiging voor je verjaardag in Star Wars-thema is dus niet strafbaar.

Goed, dan die TTL schending. Heel kort gezegd: de informatie achter domeinnamen die via nameservers wordt verspreid, heeft een houdbaarheidsdatum, de time to live of TTL. Na die TTL wordt je als ontvanger geacht die informatie opnieuw bij de bron op te vragen, zodat je niet met verouderde informatie (zoals oude IP-adressen en dus de verkeerde site) zit te werken.

De aanleiding voor de vraag was de constatering dat het voorkomt dat organisaties de TTL van andermans domeinnaaminformatie ongevraagd aanpassen. Enerzijds inkorten – zodat de bron veel vaker dan gewenst opnieuw bevraagd wordt – en anderzijds verlengen – zodat de ontvanger met mogelijk verouderde informatie werkt. Voor beide opties zijn argumenten te over.

Is dit nu valsheid in geschrifte? De makkelijke stukken: een brokje DNS informatie is een elektronisch geschrift en het wordt aangepast om het als echt door te laten gaan, want de ontvanger van de aangepaste informatie kan het niet onderscheiden van het origineel. Maar ik denk dat het hier stukloopt op de bewijsfunctie: het informatiebericht dient niet als bewijs, het is niet “wij verklaren bij deze dat onze informatie 2 dagen geldig is” maar het is een stukje informatieverstrekking met een houdbaarheidsdatum “controleer deze informatie na 2 dagen opnieuw”. Ik denk dus niet dat je er langs die route komt.

Arnoud

Deel dit artikel

  1. ik denk dat je het probleem in meerdere stukken wil knippen: ttl is namelijk niet ‘controleer dit over X tijd’, maar ‘controleer dit uiterlijk over X tijd’

    Als ik mijn interne dns vraag om blog.iusmentis.com krijg ik 86400 als ttl terug, als ik dit even later nog een keer vraag is het 86246, ik krijg namelijk als client terug ‘hoelang is de ttl op de cache nog geldig’ ipv hoe lang wil iusmentis.com dat ik dit cache. en dat is hoe het protocol werkt

    Een ttl inkorten zorgt inderdaad dat je vaker de bron gaat bevragen, echter je doet dit over het algemeen op een resolving dns server, die tevens als cache dient voor alle gebruikers er van. Andere oorzaken van vaker bevragen, geen caching, of het actief flushen van caches door bijvoorbeeld de server te herstarten. dit veroorzaakt misschien extra load

    Verlengen van de ttl is wel een probleem, als autoritive server roep je ‘dit antwoord is max 5 minuten geldig’ in het verleden deden een aantal ISP’s dit dan altijd omhoog rekken soms wel naar meer dan een dag . Hierdoor kon je als website beheerder daadwerkelijk in de problemen komen bij een migratie. doordat uren na je onderhoud verkeer nogsteeds op de oude locatie uitkwam. dit geeft bij wijzigingen een onnodig lange verstoring voor gebruikers

    • Er zijn mijns inziens twee goede redenen voor een caching dns server om de TTL aan te passen: 1) TTL is extreem lang. Dit is een mogelijke fout in de configuratie van de dns server die verantwoordelijk is voor het domein. Het lijkt me niet meer dan goed burgerschap om dan de TTL te maximeren tot bijvoorbeeld een week. 2) TTL is heel kort. Dit kan opzettelijk zijn, maar ook een foute configuratie van de dns server die verantwoordelijk is voor het domein. Het lijkt me redelijk dat een caching dns server in zo’n geval de TTL op een zeker minimum zet, bijvoorbeeld vijf minuten. Dit beschermt de caching dns server tegen overbelasting en schaadt het belang van de domeinhouder minimaal.

  2. Maakt het nog uit of je een onjuiste verwachting wekt? Dit soort technische data is helemaal in specificaties vastgelegd, dus iemand die de data opvraagt en last ondervindt van de aanpassing van de data kan redelijk goed op basis van technische specificaties beargumenteren welke verwachtingen hij had mogen hebben op basis van de inhoud van de data. Als de data verder qua poortnummer, formaat en dergelijke voldoet aan de specificaties kan je denk ik wel uitsluiten dat het om een misverstand gaat.

    Ik zou zelf ook graag een praktische kijk op de zaak hebben: wat voor schade is er nou echt? Het komt wel vaker voor dat men technische problemen oplost met een “hack”, waarbij een bestaand protocol op een manier wordt gebruikt die niet oorspronkelijk was beoogd. Het lijkt me onwenselijk dat dit allemaal wordt gejuridificeerd(*). Het lijkt me wel goed dat er wordt gestreefd naar transparantie en consensus: dat de klant kan uitzoeken wat ‘ie krijgt (incl. afwijkingen van normale standaarden) en vrij is daar niet mee akkoord te gaan.

    (*) nee, dat woord kende mijn spellingscontrole nog niet.

  3. Met deze juridische analyse, die niettemin interessant was om te lezen, gaat de discussie veel te diep. Want over de TTL is nergens expliciet vastgelegd dat die een dwingend karakter zou moeten hebben (een MUST in RFC2119 taal). Sommigen leggen het uit als een hint aan de resolver van de authoritative name server: “ik zal beloven dat dit antwoord minimaal de TTL-waarde geldig blijft en het is niet jouw schuld als dat onverhoopt niet het geval zal zijn” en dus niet als een: “gij zult exact zoveel seconden vanuit uw cache antwoord geven vooraleer gij bij mij terug komt!”, zoals de twitteraar suggereerde. Er staat ook nergens dat wat een resolver teruggeeft aan een client, gelijk moet zijn aan wat hij zelf intern als TTL hanteert of heeft geleerd van de authoritative. Er kunnen allerlei goede operationele redenen zijn om af te wijken.

  4. Bij elk antwoord van een DNS server krijg je er toch bij te zien of het een authoritive antwoord is? Ik heb van een andere DNS gehoord dat het IP adres wat je zoekt 139.162.228.112 is, en wat mij (= DNS ISP) mag je er gedurende x tijd op vertrouwen dat dit zo is. Als je het echte antwoord zou willen weten, had je het maar rechtstreeks aan de authoritive DNS moeten vragen:

    Default Server: vs-dc1-dc-01.mycompany.corp

    Address: 192.168.128.10

    blog.iusmentis.com

    Server: vs-dc1-dc-01.mycompany.corp

    Address: 192.168.128.10

    Non-authoritative answer:

    Name: iusmentis.com

    Address: 139.162.228.112

    Aliases: blog.iusmentis.com

  5. In RFC2181 staat overigens dat maximeren van de TTL gewoon mag. https://tools.ietf.org/html/rfc2181#page-10

    Implementations are always free to place an upper bound on any TTL received, and treat any larger values as if they were that upper bound. The TTL specifies a maximum time to live, not a mandatory time to live.
    en RFC1035 stelt het zelfs voor
    – As an optional step, check the TTLs of arriving data looking for RRs with excessively long TTLs. If a RR has an excessively long TTL, say greater than 1 week, either discard the whole response, or limit all TTLs in the response to 1 week.

    • Maximeren: Ja. Geen probleem. Minimum (of aanpassen naar meer dan de oorspronkelijke eigenaar bedoelde) stellen: nee. Met maximeren ligt de verantwoordelijkheid tot “onbedoeld een oude waarde meesturen” bij de persoon die de oorspronkelijke waarde stelt, bij minimeren trekt de dns-eigenaar die naar zich toe.

Laat een reactie achter

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren en <em> en <strong> voor italics en vet.

(verplicht)

Volg de reacties per RSS