6. Reverse lookups

Soms wil je niet alleen het IP-adres bij een naam zoeken, maar ook het omgekeerde: je hebt een IP-adres en je wilt weten welke naam daar bij hoort. Dit heet een reverse lookup.

Omdat je aan een IP-adres niet kunt zien tot welke zone deze behoort, is er een speciale zone waarin alle IP-adressen opgenomen kunnen worden, in-addr.arpa. Het adres wordt geschreven van 'achter naar voren' en gevraagd aan het DNS-systeem: als je de naam van 1.2.3.4 wilt weten, dan zoek je naar 4.3.2.1.in-addr.arpa.

De resource records die namen aan adressen koppelen zijn zogenaamde PTR-records. Net als bij andere RR's is het hierbij mogelijk dat een IP wijst naar meerdere namen. In de praktijk gebeurt dat echter zelden en is het feitelijk ook niet wenselijk.

Aan de hand van het netwerk van example.com zal ik een voorbeeld geven:

$TTL 1D
0.10.in-addr.arpa.      IN      SOA     ns.example.com. erik.example.com. (
                                2003040901 ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                3600000    ; expire (5 weeks 6 days 16 hours)
                                86400      ; minimum (1 day)
                                )

                        IN      NS      ns.example.com.

1                       IN      NS      ns.office.example.com.
1.0                     IN      PTR     www.example.com.
2.0                     IN      PTR     ns.example.com.
3.0                     IN      PTR     mail.example.com.

Het netwerk van example.com is 10.0.x.y. Daarbinnen is een opdeling tussen 10.0.0.x voor de webservers en dergelijke en 10.0.1.x voor het kantoor. Ik heb ervoor gekozen om de zone 0.10.in-addr.arpa hiervoor te gebruiken. Het was eventueel ook mogelijk geweest om 10.in-addr.arpa te gebruiken. Die kan meer adressen bevatten, maar dat is vaak eerder een nadeel dan een voordeel.

De zonefile in het voorbeeld bevat de reverses van 10.0.0.x en een delegatie naar ns.office.example.com voor de reverses van 10.0.1.x. Wil je bijvoorbeeld de naam van 10.0.0.2 weten, dan vraag je het PTR-record van 2.0.0.10.in-addr.arpa op, en krijg je als antwoord ns.example.com.

Wil je weten wat de naam van 10.0.1.1 is, dan gaat onze nameserver dat vragen aan ns.office.example.com omdat er een delegatie is opgenomen. Op ns.office.example.com draait de zone 1.0.10.in-addr.arpa (als alles goed is, uiteraard. Zo niet, dan is ns.office.example.com een zogenaamde lame server).

6.1 Delegaties op interne netwerken

In het voorbeeld wordt 10.0.1.x gedelegeerd naar ns.office.example.com. Maar hoe kan die server nou komen achter adressen binnen 10.0.0.*?

Het antwoord is dat ook ns.office.example.com authoritative moet worden voor de zone 0.10.in-addr.arpa. Om te zorgen dat de gegevens van 10.0.0.* niet gedupliceerd hoeven te worden naar de kantoorserver, maken we een nieuwe zone: 0.0.10.in-addr.arpa.

In de zone 0.10.in-addr.arpa komen alleen delegaties te staan naar onderliggende nameservers. Pas in de zones eronder komen de feitelijke PTR-records te staan. De zonefile voor 0.10.in-addr.arpa wordt nu:

$TTL 1D
0.10.in-addr.arpa.      IN      SOA     ns.example.com. erik.example.com. (
                                2003040901 ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                3600000    ; expire (5 weeks 6 days 16 hours)
                                86400      ; minimum (1 day)
                                )

                        IN      NS      ns.example.com.
                        IN      NS      ns.office.example.com.

0                       IN      NS      ns.example.com.
1                       IN      NS      ns.office.example.com.

Deze zone moet beschikbaar zijn op alle nameservers binnen het 10.0.x.y netwerk. Hoe dat op een makkelijke manier kan staat uitgelegd in het hoofdstuk over masters en slaves.

ns.example.com kan nu de zone voor 0.0.10.in-addr.arpa gaan draaien:

$TTL 1D
0.0.10.in-addr.arpa.    IN      SOA     ns.example.com. erik.example.com. (
                                2003040901 ; serial
                                28800      ; refresh (8 hours)
                                14400      ; retry (4 hours)
                                3600000    ; expire (5 weeks 6 days 16 hours)
                                86400      ; minimum (1 day)
                                )

                        IN      NS      ns.example.com.

1                       IN      PTR     www.example.com.
2                       IN      PTR     ns.example.com.
3                       IN      PTR     mail.example.com.

6.2 Configuratie in named.conf

Tenslotte moeten de reverse zones nog worden opgenomen in named.conf. Op ns.example.com zal dat zoiets worden:

zone "0.10.in-addr.arpa" in {
        type master;
        file "db.10.0";
};

zone "0.0.10.in-addr.arpa" {
        type master;
        file "db.10.0.0";
};

6.3 Reverses opvragen met dig

Dig vraagt altijd letterlijk om de opgegeven resource record, de volgende opdracht zal bijvoorbeeld het A-record opvragen van 10.0.0.1:

dig 10.0.0.1

dig -x 10.0.0.1

Host vraagt wel automatisch om een PTR-record als zijn argument lijkt op een IP-adres.