bind-users Digest, Vol 828, Issue 1

Parashar Singh parashar.singh2003 at gmail.com
Mon Apr 11 13:33:30 UTC 2011


Hi Torinthiel,
You have not understood my requirement. We are not looking for * to point
all A records to 1.2.3.4, but we want to delegate all * DNS request to
another Name Server, which will be taking care of request. In this case the
Name Server to which I want to delegate all * records is a GLB (Global Load
Balance).
Can you suggest on this, how to do this.

Thanks
Parashar

On Mon, Apr 11, 2011 at 8:00 AM, <bind-users-request at lists.isc.org> wrote:

> Send bind-users mailing list submissions to
>        bind-users at lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
>        bind-users-request at lists.isc.org
>
> You can reach the person managing the list at
>        bind-users-owner at lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>   1. DNS record delegation (Parashar Singh)
>   2. Re: DNS record delegation (Torinthiel)
>   3. Re: A beginners question regarding a caching-only name server
>      (Patrick Rynhart)
>   4. Re: BIND9 fails resolving after connecting to VPN (kapetr)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 11 Apr 2011 00:12:36 +0530
> From: Parashar Singh <parashar.singh2003 at gmail.com>
> Subject: DNS record delegation
> To: bind-users at lists.isc.org
> Message-ID: <BANLkTikxAywQFB7LO5TGXVyyCVtpyPs_NQ at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> We want to be able to point the wild card (*.domain.com) and the root
> domain
> (domain.com) to the GLB?s while not breaking the other custom prefixes
> within that domain?s record (stage.domain.com, foo.domain.com, etc.).
> Except some 10-20 A records, as declared in zone file, for all other DNS
> lookup request shall be forwarded to Global Load Balancer.
> Allow any records on the DNS server to resolve to the respective records on
> DNS.
> All other records are captured by the wildcard and load balanced.
> The load balancers will forward the queries to the Apache web servers which
> will direct users to the appropriate website.
>
> Can you suggest, how we can configure BIND to do above setup.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20110411/6c8c2e77/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Sun, 10 Apr 2011 22:38:05 +0200
> From: Torinthiel <torinthiel at data.pl>
> Subject: Re: DNS record delegation
> To: bind-users at lists.isc.org
> Message-ID: <4DA2152D.90004 at data.pl>
> Content-Type: text/plain; charset="windows-1252"
>
> On 04/10/11 20:42, Parashar Singh wrote:
> > We want to be able to point the wild card (*.domain.com
> > <http://domain.com>) and the root domain (domain.com
> > <http://domain.com>) to the GLB?s while not breaking the other custom
> > prefixes within that domain?s record (stage.domain.com
> > <http://stage.domain.com>, foo.domain.com <http://foo.domain.com>,
> etc.).
> > Except some 10-20 A records, as declared in zone file, for all other DNS
> > lookup request shall be forwarded to Global Load Balancer.
> > Allow any records on the DNS server to resolve to the respective records
> > on DNS.
> > All other records are captured by the wildcard and load balanced.
> > The load balancers will forward the queries to the Apache web servers
> > which will direct users to the appropriate website.
> >
> > Can you suggest, how we can configure BIND to do above setup.
>
>
> if you type
> *.domain.com. IN A 1.2.3.4
> in your zone file, bind interprets this as
> "every record that is not configured otherwise should get a record of
> type A and value 1.2.3.4"
>
> So, if I understand correctly what you want to do, just specify normal A
> records for special domains and root domain as well, and add the
> wildcard record.
>
> For this example assume 1.2.3.4 is IP of GLB, and 4.3.2.1 is IP of
> machine serving other stuff.
> So the following zone fragment should work
>
> $ORIGIN domain.com.
> @ SOA (...)
> @ NS ...
> @ A 1.2.3.4
> stage A 4.3.2.1
> foo  A 4.3.2.1
> * A 1.2.3.4
> END FRAGMENT
>
> of course stage and foo can have different IP addresses, and you
> probably want to add MX and other records as well.
> Torinthiel
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 262 bytes
> Desc: OpenPGP digital signature
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20110410/2bfe661c/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 11 Apr 2011 17:02:22 +1200
> From: Patrick Rynhart <P.Rynhart at massey.ac.nz>
> Subject: Re: A beginners question regarding a caching-only name server
> To: bind-users at isc.org
> Message-ID: <inu20v$uk8$1 at dough.gmane.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Andrew,
>
> On 9/04/2011 12:37 a.m., andrew wales wrote:
> >
> > Remember that rndc dumpdb doesn't actually dump the cache to stdout.
> > Has it actually written to named_dump.db in named's working directory?
> > Regards,
> >
> > Andrew
>
> Thanks - you are spot on here :-)  I was expecting the DB to be written
> to stdout.  One thing that I have noticed, however, is that only
> information relating to the most recently resolved DNS hostname is being
> dumped.  (If I set my /etc/resolv.conf on my client accordingly and then
> ping a bunch of different domains then I only get results for the last
> query.) Perhaps this because I have a "forwarders" directive (i.e. BIND
> is not actually functioning as a caching name server at present ?).
>
> Cheers,
>
> Patrick
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 11 Apr 2011 13:18:39 +0200 (CEST)
> From: "kapetr" <kapetr at mizera.cz>
> Subject: Re: BIND9 fails resolving after connecting to VPN
> To: stacey.marshall at gmail.com, bind-users at lists.isc.org
> Message-ID: <437b144354563f43d8fba089177a18f4 at mail2.volny.cz>
> Content-Type: text/plain; charset="iso-8859-2"
>
> Hello,
>
> interesting ...
>
> ----- P?VODN? ZPR?VA -----
> Od: "Stacey Marshall" <stacey.marshall at gmail.com>
> Komu: "kapetr" <kapetr at mizera.cz>
> P?edm?t: Re: BIND9 fails resolving after connecting to VPN
> Datum: 9.4.2011 - 22:50:44
>
> > I' wondering if the network your attaching to via
> > VPN allows direct DNS
> > lookups?
> >
> > I know of networks where the provided servers have
> > firewall rules that allow
> > them to make queries but other servers are not.
> >
> > You could test this theory by trying to connect to
> > a root server with dig
> > when connected to VPN.  For example:
> >
> > $ dig @h.root-servers.net. www.seznam.cz
> >
> > Regards,  Stace
>
>
> Why should VPN provider filter (disable) direct queries and allow
> only recursive queries ?
>
> The results are (for me) surprising:
>
> 1. before VPN: my (127.0.0.1) and ISPs servers work OK and:
> ********************************************************************
>
> hugo at duron650:~$ dig @h.root-servers.net. www.seznam.cz
>
> ; <<>> DiG 9.7.1-P2 <<>> @h.root-servers.net. www.seznam.cz
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20035
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 10
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;www.seznam.cz.                 IN      A
>
> ;; AUTHORITY SECTION:
> cz.                     172800  IN      NS      a.ns.nic.cz.
> cz.                     172800  IN      NS      b.ns.nic.cz.
> cz.                     172800  IN      NS      c.ns.nic.cz.
> cz.                     172800  IN      NS      d.ns.nic.cz.
> cz.                     172800  IN      NS      f.ns.nic.cz.
>
> ;; ADDITIONAL SECTION:
> a.ns.nic.cz.            172800  IN      A       194.0.12.1
> b.ns.nic.cz.            172800  IN      A       194.0.13.1
> c.ns.nic.cz.            172800  IN      A       194.0.14.1
> d.ns.nic.cz.            172800  IN      A       193.29.206.1
> f.ns.nic.cz.            172800  IN      A       193.171.255.48
> a.ns.nic.cz.            172800  IN      AAAA    2001:678:f::1
> b.ns.nic.cz.            172800  IN      AAAA    2001:678:10::1
> c.ns.nic.cz.            172800  IN      AAAA    2001:678:11::1
> d.ns.nic.cz.            172800  IN      AAAA    2001:678:1::1
> f.ns.nic.cz.            172800  IN      AAAA    2001:628:453:420::48
>
> ;; Query time: 144 msec
> ;; SERVER: 128.63.2.53#53(128.63.2.53)
> ;; WHEN: Mon Apr 11 12:56:18 2011
> ;; MSG SIZE  rcvd: 338
>
> hugo at duron650:~$
>
> 2. after  VPN up:
> ****************************************************************
> - my (127.0.0.1) fails again - "connection timed out; no servers
> could be reached"
> - ISPs server OK again - I get normal "A" answer
> - DNS root server - by name (IP get from ISPs server) or by IP
> gives:
> hugo at duron650:~$ dig @h.root-servers.net. www.seznam.cz
>
> ; <<>> DiG 9.7.1-P2 <<>> @h.root-servers.net. www.seznam.cz
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2758
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.seznam.cz.                 IN      A
>
> ;; ANSWER SECTION:
> www.seznam.cz.          203     IN      A       77.75.72.3
>
> ;; Query time: 67 msec
> ;; SERVER: 128.63.2.53#53(128.63.2.53)
> ;; WHEN: Mon Apr 11 12:58:52 2011
> ;; MSG SIZE  rcvd: 47
>
> hugo at duron650:~$
> *************************************************
>
> So why the h.root-servers.net == 128.63.2.53 in case 2 (over VPN)
> gives the recursive answer ?
>
> Do You thing, that this VPN provider
> - blocks direct (not recursive) DNS questions and
> - manipulates recursive queries ? [catch them, make query itself and
> answers with manipulated server IP]
>
> ???
>
> --kapetr
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> End of bind-users Digest, Vol 828, Issue 1
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110411/4f49fdc3/attachment.html>


More information about the bind-users mailing list