Misschien. Maar wat is het probleem? 

KPN geeft dus soms `NXDOMAIN` terug in plaats van de correcte response. Voor bijvoorbeeld developers welke een loopback connectie gebruiken voor testen kan dat onhandig zijn. Dan werkt het soms bij de ene persoon wel, en bij de andere niet. Bonuspunten als het bij iemand thuis wel werkt omdat die Ziggo heeft, en niet bij zodra die persoon naar zijn/haar partner gaat met KPN.

Feitelijk heb je gelijk. zodra de authoritive server van het nip.io domain als ipadres bij het a record 127.0.0.1 heeft staan zou de response van de dns netjes 127.0.0.1 moeten zijn. 

In praktijk heeft alleen de host (als hij daadwerkelijk bestaat) 127.0.0.1.nip.io last van deze response en heeft elke andere machine voldoende aan een NXDOMAIN response. En voor de host 127.0.0.1.nip.io is een dns request sturen om te achterhalen wat het local loopback adres is ook niet meteen de meest efficientste… want dat weet de machine natuurlijk al.

Een dns server gebruiken om 127.x,x,x te laten retourneren is eigenlijk maar voor 1 doel nodig. en dat voor adblock functies om op die manier domeinen te kunnen blokkeren. Waarvoor een NXDOMAIN  response hetzelfde effect heeft.

127.x.x.x is een lokale range en zou dus lokaal afgehandeld moeten worden… Voor een client betekent dat feitelijk de host file. Kijk je naar het OSI model word het 127.x.x.x daadwerkelijk op de link laag afgehandeld komt die nooit op de fysieke laag uit dus heeft het netwerktechnisch niets buiten de machine zelf te zoeken. 

In dit betoog ga je er wel vanuit dat een client weet dat er een `127.0.0.1` ip teruggegeven gaat worden. Dat is natuurlijk niet altijd het geval. Dat voor sommige gevallen een `NXDOMAIN` response niet uitmaakt maakt qua standaard niet zoveel uit: DNS servers dienen niet spontaan sommige waarden te wijzigen. 

Daarnaast is het gedrag niet consistent: de gehele 127.0.0.0/8 range is bedoeld voor loopback, maar slechts 1 van de 16777216 adressen wordt gefilterd. Het is daarmee ook inconsistent voor clients welke, om welke reden dan ook, op een ander adres luisteren. Een wijziging van het gedrag zou echter https://www.rfc-editor.org/rfc/rfc5782 catastrofaal slopen, dus daar zou ik ook geen voorstander van zijn ;)

Als illustratie een (ruwweg) voorkomend geval waar ik tegenaan gelopen was: Developers welke externe systemen mappen via dns entries. Een voorbeeld zou een developer zijn welke een frontend ontwikkeld voor een fictief `api.kpn.com` domein. In productie zorgt de DNS server binnen het webcluster ervoor dat de betreffende frontend server met de correcte backend server praat. Als een developer beiden op zijn eigen systeem heeft draaien ten behoeve van ontwikkeling kan er een loopback via DNS nodig zijn. Een case die nu onnodig geblokkeerd wordt. En een case die selectief optreedt: Ziggo heeft dit bijvoorbeeld niet. 

Tenslotte is er semantisch een verschil tussen NXDOMAIN en 127.0.0.1, zeker op het gebied van negative caching binnen DNS. Op het kpn.com domain zelf is de negative caching 1 dag, terwijl het fictieve A-record voor `api.kpn.com` met waarde `127.0.0.1` een expliciet andere waarde had kunnen staan.

Alles bij elkaar bekeken zie ik het voordeel van het rewriten nog niet in, maar de nadelen wel. Wat zouden de redenen zijn om juist wel voor zo’n rewrite te kiezen?

Nee, ik ga niet van uit dat client weet dat er een 127.0.0.1 adres terug kan geven. Ik ga ervan uit dat een 127..x.x.x nooit terug gegeven door iets buiten de host zelf.  RFC 5735: Special Use IPv4 Addresses (rfc-editor.org) en RFC 1122: Requirements for Internet Hosts - Communication Layers (rfc-editor.org) zijn redelijk uitgesproken over het correcte gebruik van de 127 reeks.

Je illustratie is een case (en zo zijn er velen) die je in moet realiseren door een entry in je hosts file, die staat lokaal en word als eerste aangeroepen bij een dnsrequest van de client. Dan voldoe je aan alle rfc’s. 

Nu zie ik de voordelen zo 1 2 3 ook niet van het rewriten. en het is niet logisch dat dit alleen voor het 1e ip van de reeks geld. Ik zou zelf zeggen dat de correcte response op een request wat 127.x.x.x op levert een YXDOMAIN zou moeten zijn

Maar aangezien het een moedwillige aanpassing is (tis iig niet een default op het moment dat je een DNS server opzet)ga ik ervan uit dat er een reden achter zit, nu ken ik die reden niet, maar ik gok dat er een adblocking achtige reden achter zit.

Ik zou verwachten op basis van https://www.rfc-editor.org/rfc/rfc5782 dat een `127.0.0.1` adres wel in een DNS respons mag staan, maar niet mag voorkomen in de routeringinformatie van het TCP protocol. Zo lees ik RFC 1122 en RFC 5735 ook. Het is prima als payload, maar je mag er niet heen adresseren.