Reading time: 5 – 8 minutes

A la feina tenim assignades 8 IPs públiques, o sigui que tenim una subxarxa (subnetting) de 8 IPs públiques cedides pel nostre ISP. El tema esta en que ens hem decidit a contractar l’auto-gestió de la resolució inversa de les IPs. En poques paraules que quan algú entri una IP del nostre rang aquesta es resolgui convenienment amb els nostres mnemonics i usant els nostres servidors. Perquè això passi els servidors DNS superiors (de la classe C) han de cedir el control del subrang d’IPs als servidors que nosaltres desitgem, en aquest cas, servidors de dintre el rang.

El problema esta en que després de que l’ISP fes els canvis pertients no ens va dir com haviem de preparar el nostre DNS per tal de fer això. Com que sempre que he fet això o ho he contractat i ja estava tot fet o bé era una xarxa de tipus C privada, mai havia tingut problemes de configuració ja que es fa igual que en tots els manuals, o sigui, trivial.

Doncs bé el problema va venir quan vaig veure que algo havia d’anar diferent i les ajudes que havia rebut no em donaben la solució així que vaig recorrer al Pof que tampoc se’n va sortir, així que espero explicar el tema prou bé com perquè almenys ell ho entengui. Abans de seguir amb el rotllo tècnic us sito les fonts d’on he tret la documentació per aconseguir que funcioni el tema:

• DNS for Rocket Scientists fantàstica llista de recursos on hi ha tot tipus d’exemples de com montar un DNS, jo diria que amb el que hi ha aquí no et fa falta res més per saber dels DNS.
• HOWTO Delegate Reverse Subnet Maps document extret de la llista anterior que com podeu deduir ens dona alguns exemples de com montar el que he comentat abans.
• DNS Stuff un site, on es poden fer totes les proves que es pot arribar a necessitar per comprobar que un DNS públic funciona bé i algunes coses més.

Centrant-nos en el problema, resulta que si aplico literalment l’exemple del link que he citat abans (HOWTO Delegate Reverse Subnet Maps) no funcionava malgrat el servei de named no donava cap error i es llençava correctament. Raro,eh!? ni en local ni en remot no funcionava res de res. Doncs bé tota la gràcia del tema esta en com el DNS que ens esta fent el re-enviament de zona s’esta referint al nostre SOA, m’explico amb l’exemple del HOWTO esmentat.

Fitxer de la zona de tipus C (192.168.23.0/24):

$ORIGIN 23.168.192.IN-ADDR.ARPA.
@            IN  SOA   ns1.isp.com. root.isp.com. (
                              2003080800 ; serial number
                              2h         ; refresh
                              15m        ; update retry
                              2w         ; expiry
                              3h         ; minimum
                              )
              IN  NS      ns1.isp.com.
              IN  NS      ns2.isp.com.
; definition of other IP address 0 - 63
....
	; definition of our target 192.168.23.64/27 subnet
; name servers for subnet reverse map
64/27         IN  NS  ns1.mydomain.com.
64/27         IN  NS  ns2.mydomain.com.
; IPs addresses in the subnet - all need to be defined
; except 64 and 95 since they are the subnets
; broadcast and multicast addresses not hosts/nodes
65            IN  CNAME   65.64/27.23.168.192.IN_ADDR.ARPA. ;qualified
66            IN  CNAME   66.64/27 ;unqualified name
67            IN  CNAME   67.64/27
....
93            IN  CNAME   93.64/27
94            IN  CNAME   94.64/27
; end of 192.168.23.64/27 subnet
.....
; other subnet definitions

Imaginem que el nostre servidor de l’empresa serà ns1.mydomain.com i que les IPs de l’empresa són 192.168.23.64/27. Doncs bé la gràcia del tema és que quan diu:

64/27 IN NS ns1.mydomain.com.

EL 64/27 NO ÉS UN DIRECCIONAMENT SINÓ UN NOM!!! aquesta era el coi de gràcia. Si mirem altres manuals veurem que a vegades es refereix a la subzona amb “un nom” (qualsevol) que no té res a veure amb la seva direcció de xarxa (com passa a l’exemple). Això feia que em perdés i no sabés que coi havia de posar. Ja que de forma lògica tot semblava indicar que això era una adreça de subnetting no un nom, segons aquest HOWTO, és clar.

Així doncs el meu problema és que el meu DNS superior es referia a aquest “nom” com a 64-27 i no com a 64/27. Per això quan em fallava una resolució em deia, per exemple, que demanava la IP: 192.168.23.64-27.68 i jo no entenia que volia dir això. Doncs bé, quan jo al meu named.conf i al meu fitxer de zona inversa posava 64/27 tal i com indica el manual del que parlo havia de posar 64-27. Ja que ell espera aquest nom, NO ADREÇA DE SUBNETTING. Per això, no hi havia manera d’entendre què estava malament.

Kit-Kat: sé que m’he fet pesat amb tan repetir el mateix, però és que el tema m’ha fet suar molt.

Penseu que si al named.conf indico això:

zone "64/27.23.168.192.in-addr.arpa" in{
	type master;
	file "192.169.23.rev";
};

Sintàcticament és igual de correcte que això altre:

zone "64-27.23.168.192.in-addr.arpa" in{
	type master;
	file "192.169.23.rev";
};

Per això podia llençar el named sense que donès cap error. Que funcioni o que no funcioni, depèn només del que indiqui el nostre DNS superior (el de la zona C). Que en el meu cas no era com l’exemple del HOWTO sinó com el segon cas que he exposat (64-27).

Així doncs el fitxer de zona inversa del HOWTO original comença així:

$ORIGIN 64/27.23.168.192.IN-ADDR.ARPA.
...

Que en el meu cas havia de ser així:

$ORIGIN 64-27.23.168.192.IN-ADDR.ARPA.
...

Ara si que sembla que parli d’una zona quan dic 64-27, doncs no, és un nom!!! en algún manual ho he vist que posava, per exemple: servidor1.23.168.192.IN-ADDR.ARPA. aquesta ha estat la gràcia per arribar a la solució.

Doncs per descobrir aquesta tonteria no sabeu la de dies que m’he passat donant-hi voltes, tampoc i he pogut dedicar ni un dia sencer a pensar en això. Però és clar, quan penses que ho fas tot bé, no dona error i no va… poc més se t’acudeix. Espero que això serveixi perquè ningú més passi pel que he passat jo aquests dies amb aquest problema.