Custom TLD over VPN

[analog_]

Ik ben bezig samen met een aantal vrienden met een VPN netwerk. Momenteel zijn er al een vijf tal locaties op aangesloten en verloopt de routering prima. Omdat IPv4 en v6 addressen onthouden inmiddels toch enkele jaren outdated is draaien we een DNS oplossing (op bind9). We willen een custom TLD (.lan) gebruiken waaronder dan deelnemers hun domeinnamen kunnen vastleggen die ze zelf willen gebruiken. Uiteindelijk moet de deelnemer kiezen of hij zelf zijn domein wilt draaien of centraal (waar ook .lan gehost wordt). Op deze manier zou een deelnemer zijn eigen zones die hij lokaal draait ook kunnen gebruiken tijdens VPN uitval (cache is geen oplossing hier).

De zone file hieronder is de .lan. zone die op de centrale server draait (192.168.1.22), deze wordt inmiddels ook al gesynct naar alle andere locaties (deze worden echter niet vermeld in de "@ NS <entries>"). Afgaande van de config kan ik vanuit de centrale locatie dus niet "iets.hoet.lan" bereiken, dit werkt wel als ik de vraag direct stel aan 192.168.[3-4].2.

code:

$ORIGIN lan.
$TTL    604800
@       IN      SOA     lan. root.localhost. (
                        2011032501      ;
                        3600            ;
                        1800            ;
                        604800          ;
                        1800 )          ;
 
@               NS      ns1.lan.
@               NS      ns2.lan.
 
@               A       192.168.1.10
@               AAAA    x:n:a:1::10
 
hoet            NS      ns1.hoet.lan.
hoet            NS      ns2.hoet.lan.
 
kot             NS      ns1.kot.lan.
kot             NS      ns2.kot.lan.
 
ns1             A       192.168.1.10
ns2             A       192.168.1.22
ns1             AAAA    x:n:a:1::10
ns2             AAAA    x:n:a:1::22
 
ns1.kot         A       192.168.1.10
ns2.kot         A       192.168.1.22
ns1.kot         AAAA    x:n:a:1::10
ns2.kot         AAAA    x:n:a:1::22
 
ns1.hoet        A       192.168.3.2
ns2.hoet        A       192.168.4.2
ns1.hoet        AAAA    x:n:b:1::2
ns2.hoet        AAAA    x:n:b:2::2

De problemen die ik hier 1-2-3 kan vinden is dat niet elke DNS server (die op andere locaties) vermeldt staat in het .lan. NS <cname-entry> met bijhorend glue record. Ik kan momenteel helaas niet testen wegens gebrek aan login-credentials. Mogelijke suggesties heb ik ook al gevonden in het aanmaken van een "."-zone (root zone in feite) waarin je dan je custom TLD's definieert, deze moet dan volgens mij ook overal lokaal draaien met hetzelfde probleem wat ik hierboven al aanhaalde. Alle DNS servers inclus degene op locatie moeten dan weer @ NS gedefinieerd worden in de nieuwe root-zone. Wat zien jullie fout hierin? Wat is de correcte oplossing?

[CyBeR]

Ik begrijp niet helemaal wat je bedoelt met:

analog_ schreef op zondag 01 mei 2011 @ 00:25:
Afgaande van de config kan ik vanuit de centrale locatie dus niet "iets.hoet.lan" bereiken, dit werkt wel als ik de vraag direct stel aan 192.168.[3-4].2.

Bedoel je dat 't niet werkt, of dat je denkt dat 't niet werkt? In mijn optiek zou dat gewoon moeten werken namelijk. Zo niet heb je ergens een foutje gemaakt.

De problemen die ik hier 1-2-3 kan vinden is dat niet elke DNS server (die op andere locaties) vermeldt staat in het .lan. NS <cname-entry> met bijhorend glue record. Ik kan momenteel helaas niet testen wegens gebrek aan login-credentials. Mogelijke suggesties heb ik ook al gevonden in het aanmaken van een "."-zone (root zone in feite) waarin je dan je custom TLD's definieert, deze moet dan volgens mij ook overal lokaal draaien met hetzelfde probleem wat ik hierboven al aanhaalde. Alle DNS servers inclus degene op locatie moeten dan weer @ NS gedefinieerd worden in de nieuwe root-zone. Wat zien jullie fout hierin? Wat is de correcte oplossing?

Sowieso heb je voor alle NS'en die zich in het domein bevinden (ns1.hoet.lan voor hoet.lan) glue nodig.

Een root zone is niet strict gezien nodig, als alle recursive nameservers weten van het domein 'lan.'. Als ze daar niet expliciet van weten heb je inderdaad een root zone nodig waarin 'lan.' gedelegeerd wordt aan ns[12].lan.

[analog_]

Ik weet dat het niet werkt, als ik dus op 192.168.1.10 fracture.hoet.lan opvraag werkt het niet, op 192.168.3.2 wel. Moet ik dus volgens jouw @ IN NS ns3.lan. met ns3.lan A 192.168.3.2? Op alle locaties kan je overigens de glue records (ns1.hoet.lan en hoet.lan wel resolven). De config file is een stuk groter overigens (lees: meer van hetzelfde) maar dit is de essentie van het probleem.

Net even geprobeerd, de .lan. zone wordt doorgesynct dus dat zit wel snor, echter werkte het nog niet.

code:

May  1 01:30:34 Raiden named[20983]: client 192.168.3.2#54815: transfer of 'lan/IN': AXFR-style IXFR started
May  1 01:30:34 Raiden named[20983]: client 192.168.3.2#54815: transfer of 'lan/IN': AXFR-style IXFR ended

en de zone file met dit erbij:

code:

@               NS      ns3.lan.
@               NS      ns4.lan.
ns3             A       192.168.3.2
ns3             AAAA    x:n:b:1::2
ns4             A       192.168.4.2
ns4             AAAA    x:n:b:2::2

[ Voor 80% gewijzigd door analog_ op 01-05-2011 01:41 ]

[CyBeR]

Is die server wel recursive ingesteld dan? Doe 's de output van 'dig fracture.hoet.lan @192.168.1.10' geven?

[Kabouterplop01]

@ NS ns1.lan.
@ NS ns2.lan.

@ A 192.168.1.10
@ AAAA x:n:a:1::10

wat is jouw /etc/resolv.conf op de ns1.lan?

Ik lijk hier nl 2 records te missen.
die van de ns2 nl.
of is dat wat je met

De zone file hieronder is de .lan. zone die op de centrale server draait (192.168.1.22), deze wordt inmiddels ook al gesynct naar alle andere locaties (deze worden echter niet vermeld in de "@ NS <entries>").

bedoelt?


wat bedoel je met het werkt niet? krijg je een nxdomain of een access deneid?

[ Voor 27% gewijzigd door Kabouterplop01 op 01-05-2011 03:00 ]

[analog_]

@Kabouterplop01: die @ A 1.10 en 1::10 is wat er resolved wordt als je letterlijk .lan. intik in je browser, dat klopt volgens mij wel. De records voor ns1.lan. en ns2.lan. staan lager in de configuratie (met IPv4 en IPv6 adressen), factoid: heten glue records.

code:

Raiden:/home/analog# dig fracture.hoet.lan (zelfde output met @192.168.1.10)

; <<>> DiG 9.6-ESV-R1 <<>> fracture.hoet.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44189
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;fracture.hoet.lan.             IN      A

;; Query time: 1766 msec
;; SERVER: 2001:6f8:14a3:1::10#53(2001:6f8:14a3:1::10)
;; WHEN: Sun May  1 02:54:21 2011
;; MSG SIZE  rcvd: 35

Iets wat lokaal wel werkt:

code:

Raiden:/home/analog# dig file.kot.lan

; <<>> DiG 9.6-ESV-R1 <<>> file.kot.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25181
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;file.kot.lan.                  IN      A

;; ANSWER SECTION:
file.kot.lan.           604800  IN      CNAME   enceladus.kot.lan.
enceladus.kot.lan.      604800  IN      A       192.168.1.26

;; AUTHORITY SECTION:
kot.lan.                604800  IN      NS      ns2.kot.lan.
kot.lan.                604800  IN      NS      ns1.kot.lan.

Zover ik weet staat recursion op yes in /etc/bind/named.conf.options (het is debian squeeze).

[ Voor 8% gewijzigd door analog_ op 01-05-2011 03:08 ]

[Kabouterplop01]

Hier staat je antwoord:

Raiden:/home/analog# dig fracture.hoet.lan (zelfde output met @192.168.1.10)

; <<>> DiG 9.6-ESV-R1 <<>> fracture.hoet.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44189 <====!
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0,<====!

kijk naar de flags... Het lijkt op een lame delegation; dit concludeer ik uit het feit dat het lijkt alsof de AUTHORITY: 0 flag wordt mee gegeven

[ Voor 21% gewijzigd door Kabouterplop01 op 01-05-2011 03:08 ]

[analog_]

Die ServFail gok ik dat je bedoelt, suggesties voor debugging methodes? Logfiles doorstruinen of is er een extended log mogelijk? spec helpt weinig qua flags. Zoekt verder...

[Kabouterplop01]

het tooltje host heeft volgens mij een debug optie -d of -D (weet niet zeker welke)

[CyBeR]

Als ik 't direct aan je NS vraag, krijg ik netjes het verwachte antwoord:

# dig fracture.hoet.lan @2001:6f8:14a3:1::10

; <<>> DiG 9.3.2-P1 <<>> fracture.hoet.lan @2001:6f8:14a3:1::10
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58763
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;fracture.hoet.lan.		IN	A

;; AUTHORITY SECTION:
hoet.lan.		604800	IN	NS	ns1.hoet.lan.
hoet.lan.		604800	IN	NS	ns2.hoet.lan.

(plus een additional section met de glue erin.)

AUTHORITY:0 betekent trouwens niet dat het antwoord niet autoritatief is, maar dat er geen NS records meegestuurd zijn. Dat is een teller, geen flag. De flags staan na 'flags:'

[ Voor 13% gewijzigd door CyBeR op 01-05-2011 03:43 ]

[Kabouterplop01]

AUTHORITY:0 betekent trouwens niet dat het antwoord niet autoritatief is, maar dat er geen NS records meegestuurd zijn. Dat is een teller, geen flag. De flags staan na 'flags:'

hm ja ik had header>opcode>status moeten zeggen
hij krijgt een servfail

Ik doelde eigenlijk op dat de server terwijl die volgens mij auth is, niet antwoord als dusdanig, of zit ik mis?

meh ik kan het niet testen op ipv6, da hek nie

[ Voor 10% gewijzigd door Kabouterplop01 op 01-05-2011 12:44 ]

[analog_]

Ik heb nu overal alles zitten doorvoeren maar het werkt helaas nog steeds niet. Ik snap niet goed waar het probleem nu zit, vreemde is overigens dat een cname van bijvoorbeeld ns1.hoet.lan (die dus enkel op ns1 en ns2.hoet.lan bekend is) wel resolved, andere entries niet.

Die servfail lag aan kapot IPv6 netwerk (aiccu schoppen).

[ Voor 10% gewijzigd door analog_ op 03-05-2011 02:24 ]

[Kabouterplop01]

zijn de serials hetzelfde van alle NS-en?
(host -t soa domein.tld)

[analog_]

Ja, deze worden via AXFR doorgegeven naar elkaar.

[Kabouterplop01]

hmmm
wat staat er in de /etc/resolv.conf op de 192.168.1.10