transparently forwarding a zone
Kevin Darcy
kcd at chrysler.com
Fri Jan 18 16:10:27 UTC 2013
What do you have against Internet clients querying the storage device?
It's obvious that the storage device wants to serve that part of the DNS
namespace. If you don't want the clients to query the device "directly"
you could do it through a NAT, or proxy, or whatever. Anything other
than "direct" client/server interaction, e.g. transparent DNS
redirection, is going to be a hack job. I wouldn't want to support it.
- Kevin
On 1/18/2013 10:33 AM, Garsiot, Thomas wrote:
>
> Hi,
>
> I have an issue with domain forwarding.
>
> I'm managing public DNS servers for, say, mydomain.com.
>
> We're currently setting a storage system which relies on DNS for load
> balancing. The system is made of 4 nodes with IP addresses 10.0.0.1,
> 2, 3, 4.
>
> The vendor recommands a stub zone to be created with forwarders set to
> the 4 IP addresses (i.e their storage system acts as a mini-DNS server).
>
> However, we need this resolution to occur over the internet, so
> obviously the stub zone solution does not work because DNS resolvers
> on the internet would retrieve the NS list for the subdomain and try
> to query it directly.
>
> We need to be able to resolve on the internet anything of the format :
>
> xxxx.storage.mydomain.com or yyyy.xxxx.storage.mydomain.com
>
> so what I need is my public DNS servers to be owners of the
> storage.mydomain.com but still rely on the storage system for more
> specific host resolution.
>
> Some kind of a stealth DNS server but with a forward rather than a
> master-slave scheme.
>
> We've tried several solutions but none was fully successful.
>
> SOLUTION 1:
>
> ============
>
> in mydomain.com zone file :
>
> storage IN NS ns-storage.mydomain.com.
>
> ns-storage IN A 2.2.2.2
>
> where 2.2.2.2 is a public VIP on the internet that load balances DNS
> traffic to 10.0.0.1 -> 4
>
> SOLUTION 1 results :
>
> ====================
>
> partially works :
>
> when querying google's resolving DNS server for test, both
> xxxx.storage.mydomain.com or yyyy.xxxx.storage.mydomain.com resolve
> fine to the 4 private IP addresses.
>
> however, in certain environments, xxxx.storage.mydomain.com works but
> not yyyy.xxxx.storage.mydomain.com.
>
> My guess is that google for some reason sent a recursive query for
> yyyy.xxxx.storage.mydomain.com to the NS of storage.mydomain.com while
> the other environment was sending an iterative query and thus tried to
> query the internal addresses of the storage box.
>
> In the situation that fails what I think is happening is :
>
> Resolver -> mydomain.com NS servers : query NS storage.mydomain.com
>
> mydomain.com NS servers -> resolver : storage.mydomain.com's NS is
> ns-storage which translates to 2.2.2.2
>
> Resolver -> 2.2.2.2 : query NS for xxxx.storage.mydomain.com
>
> 2.2.2.2 -> resolver : returns 4 NS records corresponding to 10.0.0.1 ->4
>
> Resolver -> 10.0.0.1,2,3 or 4 : fails because private IP is not reachable.
>
> SOLUTION 2:
>
> ============
>
> in named.conf :
>
> zone "storage.mydomain.com" {
>
> type forward;
>
> forwarders { 2.2.2.2; };
>
> //forward only;
>
> };
>
> I've tried with and without the "forward only directive" - no change.
>
> Tried it with the internal IP addresses 10.x.x.x and external VIP 2.2.2.2.
>
> SOLUTION 2 results :
>
> ====================
>
> fails
>
> a dig for xxxx.storage.mydomain.com gives no answer. Only the
> authority section pointing to ns1.mydomain.com & ns2.
>
> SOLUTION 3 :
>
> ============
>
> in named.conf :
>
> zone "storage.mydomain.com" {
>
> type forward;
>
> forwarders { 2.2.2.2; };
>
> //forward only;
>
> };
>
> in zone file for mydomain.com
>
> storage IN NS ns1.mydomain.com
>
> storage IN NS ns2.mydomain.com
>
> SOLUTION 3 results :
>
> ====================
>
> Direct recursive query to mydomain.com name servers works fine
>
> Requests through another resolver do not work.
>
> dig xxx.storage.mydomain.com +trace gives :
>
> mydomain.com. 172800 IN NS ns1.mydomain.com.
>
> mydomain.com. 172800 IN NS ns2.mydomain.com.
>
> ;; Received 117 bytes from 192.42.93.30#53(192.42.93.30) in 102 ms
>
> storage.mydomain.com. 300 IN NS
> ns1.mydomain.com
>
> storage.mydomain.com. 300 IN NS
> ns2.mydomain.com
>
> mydomain.com. 300 IN SOA ns1.mydomain.com. xxxxxxxx
>
> 2013011801 3600 900 604800 10800
>
> I sometimes get loops with the following messages :
>
> storage.mydomain.com. 300 IN NS
> ns1.mydomain.com
>
> storage.mydomain.com. 300 IN NS
> ns2.mydomain.com
>
> ;; BAD (HORIZONTAL) REFERRAL
>
> ;; Received 117 bytes from xx in 6 ms
>
> Any advice on how to get this done ?
>
> Thanks in advance !
>
> Thomas
>
> ___________________________________________
>
> Thomas Garsiot
>
> Architecture Réseau/Network Architecture, GISSC, CGI Inc.
>
> ((514) 415-3000 #1015293 (SVP ne pas laisser de messages vocaux/
> please do not use voice mail)
> *Ê*(514) 415-3965
>
> *P***Avant d'imprimer, pensez à l'environnement...
>
>
> Avis de confidentialité : ce message peut contenir des renseignements
> confidentiels appartenant exclusivement au Groupe CGI Inc. ou à ses
> filiales. Si vous n'êtes pas le destinataire indiqué ou prévu dans ce
> message (ou responsable de livrer ce message à la personne indiquée ou
> prévue) ou si vous pensez que ce message vous a été adressé par
> erreur, vous ne pouvez pas utiliser ou reproduire ce message, ni le
> livrer à quelqu'un d'autre. Dans ce cas, vous devez le détruire et
> vous êtes prié d'avertir l'expéditeur en répondant au courriel.
>
> ___________________________________________
>
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130118/a0dd1e25/attachment.html>
More information about the bind-users
mailing list