dns server: 1 hostname overrulen

[psilin]

Mensen,

Nog steeds ben ik aan het denken over mijn 'bomen en bos vraag': mail/agenda/contacten op diverse manieren. Ik weet even niet hoe ik op dit forum kan linken naar een andere post, dus vandaar deze mededeling.

De beoogde server staat in mijn thuisnetwerk, achter een adsl router. Mijn publieke ( provider ) ip address is statisch en is zelfs voorzien van een complete fully qualified domain name (FQDN) in de vorm : hostnaam.provider.land

Als ik straks een werkende imap server heb, wil ik deze uiteraard remote én thuis kunnen benaderen. Lokaal via Wifi, remote via umts.

Nu voorzie ik een probleem aangezien als mailserver ( imap & smtp ) ik uiteraard een FQDN, vandaar dat ik middels bind een dns servertje heb opgezet zodat als ik thuis ben via de DNS server hostnaam.provider.land kan worden geresolved naar een lokaal ip address.

Echter, ik kan met bind volgens mij alleen complete domeinen van DNS voorzien. Daardoor zou al het andere verkeer (onder andere  www, ftp, ssh ) niet meer mogelijk zijn naar xxx.provider.land

Is dit ergens binnen de bind config op te lossen of zit ik op een verkeerd denkspoor ?

[testcees]

Echter, ik kan met bind volgens mij alleen complete domeinen van DNS voorzien. Daardoor zou al het andere verkeer (onder andere  www, ftp, ssh ) niet meer mogelijk zijn naar xxx.provider.land

Kies een eigen naam als domein (eigennet). Je moet geen DNS server opzetten voor het domein provider.land. Dat heeft je provider al gedaan en kan problemen geven (met xxx.provider.land). Je eigen DNS server is voor adressen in je eigen thuisnetwerk (domein).

Van buiten bereik ik de server in mijn thuisnetwerk door de FQDN hostnaam.provider.land (of ip-adres). Door de internetmodem/router worden de poorten voor imap, smtp, http, https, ssh, ... doorgestuurd (portforwarding, ge-NAT) naar eigenhost.eigennet.

Intern werkt eigenhost.eigennet maar ook hostname.provider.land, eigenhost.eigennet is soms eenvoudiger/leuker.

Offtopic: Heb je ook een DHCP server draaien zodat op alle computers automatisch je eigen DNS (en de netwerknaam eigennet) wordt ingesteld? De door DHCP uitgegeven adressen kan je zelfs dynamisch in je eigen DNS server laten opnemen, zodat alle computers te bereiken zijn met hun computernaam (of computernaam.eigennet). 8)

[psilin]

Van buiten bereik ik de server in mijn thuisnetwerk door de FQDN hostnaam.provider.land (of ip-adres). Door de internetmodem/router worden de poorten voor imap, smtp, http, https, ssh, ... doorgestuurd (portforwarding, ge-NAT) naar eigenhost.eigennet.

Intern werkt eigenhost.eigennet maar ook hostname.provider.land, eigenhost.eigennet is soms eenvoudiger/leuker.

Dat wil ik juist voorkomen. Dus zowel vanuit intern netwerk, als bij extern gebruik moet een FQDN resolven naar:
1. intern netwerk : het interne ip adres
2. externe : het publieke ip adres waar via NAT/PAT wordt doorgerouteert naar het interne ip adres

Op geen enkele andere wijze krijg ik de mobieltjes aan het hoofd geprutst dat ze bv voor mail een ander ip adres moeten gebruiken afhankelijk van de verbinding.

Op je offtopic vraag: op de adsl router draait inderdaad dhcp. Eventueel kan dat dhcp deel ook op het eigen servertje komen te staan. Eerst maar eens zien of ik het met een statische test config aan de pruttel krijg.



Kortom: ik wil eigenlijk intern mijn eigen netwerk de FQDN van de provider (dus inclusief hostnaam ) welke gelijk is aan mijn publieke ip adres op de router laten resolven naar een intern ip adres. Ik zal dit weekend eens testen of ik een 2e zone bestaande uit het provider gedeelte kan configureren. Gevoelsmatig zet ik vraagtekens of het werkzaam gaat zijn, vandaar deze vraag.

[testcees]

Van buiten bereik ik de server in mijn thuisnetwerk door de FQDN hostnaam.provider.land (of ip-adres). Door de internetmodem/router worden de poorten voor imap, smtp, http, https, ssh, ... doorgestuurd (portforwarding, ge-NAT) naar eigenhost.eigennet.

Intern werkt eigenhost.eigennet maar ook hostname.provider.land, eigenhost.eigennet is soms eenvoudiger/leuker.

Dat wil ik juist voorkomen. Dus zowel vanuit intern netwerk, als bij extern gebruik moet een FQDN resolven naar:
1. intern netwerk : het interne ip adres
2. externe : het publieke ip adres waar via NAT/PAT wordt doorgerouteert naar het interne ip adres

Kortom: Het kan te maken hebben met mijn specifieke router (een 'normale' Linksys WAG200GB) maar zoals ik schrijf werken de mobieltjes (iPhone, N97 en E51) hier ook intern via wifi met hostname.provider.land. Dit wordt (extern) omgezet in het externe adres en komt op de imap, smtp ,htpp, ssh, enz. server die is ingesteld op de router (portforward).

[psilin]

Dat zal ongetwijfelds te maken hebben dan inderdaad met welke router / firmware er gebruikt wordt. Zelf gebruik ik een speedtouch variant, en zoals het een goed NAT/firewall apparaat betreft accepteert deze niet dat vanuit het interne netwerk via outbound NAT naar het eigen externe adres via een inbound nat naar een buur host connect. Beveiligingstechnisch wordt op deze wijze spoofing voorkomen.

[psilin]

Zo na een paar uurtjes denken en frutselen heb ik het werkend. Dit door middel van het aanmaken van een extra zone in /etc/bind/named.conf.local:

Code: [Selecteer]

# This is to overrule hostnaam.provider.land ip address when on local LAN
zone "hostnaam.provider.land" IN {
        type master;
        file "/etc/bind/zones/hostnaam.provider.land.db";
        };

Vervolgens een zone file /etc/bind/zones/hostnaam.provider.land.db:

Code: [Selecteer]

hostnaam.provider.land.db
$TTL 3D
@ IN SOA hostnaam.provider.land. root (
        2009091208      ; serial date
        28800           ;refresh
        3600            ;retry
        900             ;expire
        360             ;minimum
);
@               IN      NS              10.0.0.200  ; lokale server waar bind op draait
@               IN      A               10.0.0.200  ; non FQDN adres

En aangezien hostnaam.provider.land via de externe hosting dns resolved naar het externe ip adres hoeft er geen reverse database file aangemaakt te worden.


De gebruikte truuk is om  in BIND een zone te definiëren waar verder geen enkele host inzit. Bind ziet deze zone file als zijnde subdomein. De regel @ IN A 10.0.0.200 laat BIND vervolgens antwoorden op de volgens BIND non FQDN hostnaam.provider.land ( immers als zijnde een subdomein verwacht BIND server.hostnaam.provider.land als lookup request ) met het adres 10.0.0.200.

-- edit nav melding in syslog --
in de syslog kwam een melding te staan: IN: NS 'hostnaam.provider.land' has no address records (A or AAAA). Hoewel deze melding de werking van voorgaande oplossing niet aantast vind ik het ergerlijk om dit soort meldingen te krijgen.

aangepaste  /etc/bind/zones/hostnaam.provider.land.db:

Code: [Selecteer]

$TTL 3D
@ IN SOA ns1.hostnaam.provider.land. root (
        2009091208      ; serial date
        28800           ;refresh
        3600            ;retry
        900             ;expire
        360             ;minimum
);
@               IN      NS              ns1.hostnaam.provider.land
@               IN      A               10.0.0.200  ; non FQDN adres
ns1             IN      A               10.0.0.200  ; server waar BIND op draait

Nu zit er in het subdomein hostnaam.provider.land dus 1 host met de naam ns1. Resultaat: foutmelding weg ;-)


Weer een klein stapje verder dus ;-)