Re: Why two lookups for a CNAME?

[Steve Arntzen]

Thank you all for the suggestions.

Prefetch sounds like a good solution and still provides the designed behavior
for integrity.  I see Bind 9.10 introduces “prefetch” and I will look into it.

Until we change or upgrade, a simple solution may be our own prefetch (periodic
lookup) of popular CNAMES (as we see them in logs).

I will share the options and suggestions to those who decide.

(sorry for the TOFU)

Steve.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Why two lookups for a CNAME?

[Steve Arntzen]

I fully agree.


Now, please understand the following question has been asked of me and I fully
realize the implications and that it is just not a good idea.  I will gladly
forward the suggestions to my peers (and bosses).


Is there any way to accept the first response (CNAME with IP) and not perform
the second look up?


The reason is, when our Bind server is communicating over a satellite link with
a 600 ms round trip time per transaction, the delay becomes noticeable (>1.2
seconds for a single CNAME resolution).  Add to that, some of the CNAMES have
short TTLs, so this happens periodically.


As a test, I tried forwarding (and forward only) google.com to Google's public
DNS server.  Although the packets did go directly to 8.8.8.8 as expected, my
Bind server still (for safe verification) performed the second look up.  Note,
the requesting client using dig, sends out one request and receives one reply.
 The test was for "play.google.com".


If anyone has suggestions, please toss them my way.  "Let it work as designed
and deal with it" or similar comments will be graciously accepted.


Thanks again,


Steve.



> 
> On October 22, 2015 at 7:07 AM Reindl Harald 
> wrote:
> 
> 
> 
> 
> Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas:
> > On 22.10.15 08:01, Mark Andrews wrote:
> >> To prevent cache poisoning via cnames. It it simpler to always
> >> lookup the target of the cname that to figure out if we would
> >> accepted the following data.
> >>
> >> server A has zones foo.example and bar.example configured
> >> server B has zone bar.example configured
> >>
> >> bar.example is only delegated to server B of the two server above.
> >>
> >> The is a cname from www.foo.example -> www.bar.example
> >>
> >> Server A return a complete answer but the www.bar.example data is
> >> from the wrong zone instance. This happens accidentally in real
> >> life.
> >
> > I wonder if it's not enough to verify that the first response was
> > received
> > from proper server.
> >
> > Since play.l.google.com is a subdomain of play.google.com, the lookup
> > would
> > go throuth google.com nameservers again...
> >
> > when servers for bar.example are the same as servers for foo.example,
> > the
> > already accepted answer for foo.example is expected to contain valid
> > answer
> > for bar.example too...
> 
> well, it's better to keep things simple and whenever possible working
> the same way instead premature optimization and different behavior to
> keep them clear and maintainable
> 
> at the end it does not matter
> 
> most DNS results are coming from caches and if they are not in the cache
> they are not frequent enough that it would matter
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Why two lookups for a CNAME?

[Steve Arntzen]

Makes sense.  Better safe than sorry.


Thanks,


Steve.


> 
> On October 21, 2015 at 4:01 PM Mark Andrews  wrote:
> 
> 
> 
> To prevent cache poisoning via cnames. It it simpler to always
> lookup the target of the cname that to figure out if we would
> accepted the following data.
> 
> server A has zones foo.example and bar.example configured
> server B has zone bar.example configured
> 
> bar.example is only delegated to server B of the two server above.
> 
> The is a cname from www.foo.example -> www.bar.example
> 
> Server A return a complete answer but the www.bar.example data is
> from the wrong zone instance. This happens accidentally in real
> life.
> 
> Mark
> 
> In message
> <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg
> t.hosting.qts.netsol.com>, Steve Arntzen writes:
> >
> > I'm sure there's a good, simple reason for this, I just can't seem to
> > find th
> > e
> > answer searching on the Internet.
> >
> >
> > Why does named perform a lookup for the A record when its IP is returned
> > with
> > the CNAME in the first answer?
> >
> >
> > Using dig, I find play.google.com is a CNAME for play.l.google.com.
> >
> >
> > When asked to resolve it, named will first look for play.google.com. The
> > res
> > ult
> > will include the CNAME and the IP of the A record.
> >
> >
> > Named then makes a second request to resolve the A record.
> >
> >
> > Thanks in advance,
> >
> >
> > Steve.
> > --=_Part_15947_1241356502.1445459552087
> > MIME-Version: 1.0
> > Content-Type: text/html; charset=UTF-8
> > Content-Transfer-Encoding: 7bit
> >
> >  > "http://www.w3.org/T
> > R/xhtml1/DTD/xhtml1-strict.dtd">
> >
> > http://www.w3.org/1999/xhtml";>
> > 
> > I'm sure there's a good, simple reason for this, I j
> > ust can't seem to find the answer searching on the
> > Internet. > p>Why does named perform a lookup for the A record when its IP is
> > returned
> > with the CNAME in the first answer?Using dig, I find
> > play.
> > google.com is a CNAME for play.l.google.com.When asked
> > to r
> > esolve it, named will first look for play.google.com.  The result will i
> > nclude the CNAME and the IP of the A record.Named then
> > make
> > s a second request to resolve the A record.Thanks in
> > advanc
> > e,Steve.
> > --=_Part_15947_1241356502.1445459552087--
> >
> > --===7115022951714415033==
> > Content-Type: text/plain; charset="us-ascii"
> > MIME-Version: 1.0
> > Content-Transfer-Encoding: 7bit
> > Content-Disposition: inline
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe
> > from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> > --===7115022951714415033==--
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Why two lookups for a CNAME?

[Steve Arntzen]

Thank you Jeff.


I was just wondering why, when the IP comes back with the first response, does
named ask again?


Is it just being literal (like me) or will it not always get the IP in the first
request (depending on the DNS server)?


Steve.





> On October 21, 2015 at 3:42 PM "Lightner, Jeff" 
> wrote:
> 
> 
> Because the purpose of DNS primarily is to equate a name with an IP as
> applications talk to IPs not to names.   When you have a CNAME you’re equating
> one name with another name.   That other name then has to be looked up so the
> application knows what IP access.
> 
>  
> 
> This saves time if you have multiple CNAMES to the same A record in that
> when you update DNS you only have to update that one A record.  You don’t have
> to use CNAMES to go to same IP – you could make each record an A record
> pointing to the same IP.   You’d then have to be sure you updated all the A
> records using that IP if you decided to change it to something else later
> (e.g. if you changed ISPs).
> 
>  
> 
> Obviously there is a small performance cost in CNAMES which is why you
> don’t want to have a CNAME to  another CNAME because that results in 3
> lookups.   For most applications the single CNAME isn’t an issue but on
> occasion it is so you go the A record route instead.
> 
>  
> 
>  
> 
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen
> Sent: Wednesday, October 21, 2015 4:33 PM
> To: bind-users
> Subject: Why two lookups for a CNAME?
> 
>  
> 
> I'm sure there's a good, simple reason for this, I just can't seem to find
> the answer searching on the Internet.
> 
>  
> 
> Why does named perform a lookup for the A record when its IP is returned
> with the CNAME in the first answer?
> 
>  
> 
> Using dig, I find play.google.com is a CNAME for play.l.google.com.
> 
>  
> 
> When asked to resolve it, named will first look for play.google.com.  The
> result will include the CNAME and the IP of the A record.
> 
>  
> 
> Named then makes a second request to resolve the A record.
> 
>  
> 
> Thanks in advance,
> 
>  
> 
> Steve.
> 


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Why two lookups for a CNAME?

[Steve Arntzen]

I'm sure there's a good, simple reason for this, I just can't seem to find the
answer searching on the Internet.


Why does named perform a lookup for the A record when its IP is returned with
the CNAME in the first answer?


Using dig, I find play.google.com is a CNAME for play.l.google.com.


When asked to resolve it, named will first look for play.google.com.  The result
will include the CNAME and the IP of the A record.


Named then makes a second request to resolve the A record.


Thanks in advance,


Steve.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

9.9.4 Bug Fixes - RT #34583

[Steve Arntzen]

Good morning/day/evening.

What exactly does "beneath" mean in the following line from the 9.9.4
bug fixes?

"Fix forwarding for  forward only "zones" beneath automatic empty zones.
[RT #34583]"

Thanks in advance,

Steve.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Multiple BIND instances

[Steve Arntzen]

On Mon, 2012-02-06 at 23:09 -0800, sasa sasa wrote:
> Hi,
> I got a server with 16GB memory, want to install 2 BIND on CentOS, one cache 
> only and another authoritative.
> Is it better to install 2 OS virtually and run BIND in them or run 2 
> instances of BIND on the same OS? I mean what is the best practice to take 
> advantage of the hardware resources without risking having single DNS with 
> cache and authoritative?
> 
> regards,
> Sasa

How many CPU cores do you have?

I've been running Debian with BIND (some with multiple views) on Xen for
a few years now.  Each box has five virtual servers, some of them
running >1,000 lookups/second with plenty of CPU overhead.

The boxes are dual hex-core AMDs with 32GB RAM.  The individual virtual
servers are running 2 cores each.  The boxes have up times of over 600
days with no issues.

I'm not suggesting this is what you should do, but rather showing it has
been a very successful and cost effective solution for me.  You should
evaluate the expected DNS load and test accordingly. I tested my servers
with several times our current load before deployment.

Steve.

BIND Rocks.


> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec question. confused.

[Steve Arntzen]

Is your firewall Cisco based?

There is a known "default" setting in Cisco with respect to packet size
for DNS.  Our network guys run into this anytime they do an upgrade,
etc. and have to go in and update the setting.

Steve.



On Tue, 2011-09-27 at 15:45 -0500, Brad Bendily wrote:
> When trying the DNSSEC check command from:
> https://www.dns-oarc.net/oarc/services/replysizetest
> 
> behind our corporate firewall, I get:
> rst.x476.rs.dns-oarc.net.
> rst.x485.x476.rs.dns-oarc.net.
> rst.x490.x485.x476.rs.dns-oarc.net.
> "Tested at 2011-09-27 20:32:34 UTC"
> "205.172.49.177 sent EDNS buffer size 4096"
> "205.172.49.177 DNS reply size limit is at least 490"
> 
> 
> Which, based on the website tells me our firewall is blocking 
> or filtering EDNS/DNSSEC packets.
> 
> 
> 
> However, what I'm confused about is when I run this command:
> dig +dnssec eeoc.gov
> 
> I get:
> 
> ; <<>> DiG 9.7.3-P1 <<>> +dnssec eeoc.gov
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40572
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;eeoc.gov.  IN  A
> 
> ;; ANSWER SECTION:
> eeoc.gov.   19499   IN  A   64.94.64.52
> eeoc.gov.   19499   IN  RRSIG   A 7 2 21600 20111208014816 
> 20110909014816 52909 eeoc.gov. 
> AW5Ny32xDP7+m4XxCSS7q/zuK8RBc+la70Zmg0A/Pe1+p0agkrzbxaHM 
> GgvKldSKCzVgo7XPGR3LqcGIFDl0CPaaSTxTntlZkdh6x2qS4mM/49+B 
> 9podxzbV3V4LcNpR4c4jyteAa5Uxaz3WSRr1T69PpJyIZZ53JmexkMPi 
> yOjMcp1IqeSJ0P/06CuZccemo+f/fjGW8xfG/slOp2XJlmbPo1EfJnlw 
> i07YstZVszHxsgmRUXssEUmkWi3eqAw4Ug2QiRa+zz3JpmgBnC0G7Kxd 
> SXUJLuvfNdDrtJ9T5anNVRVxCVq499gaJQnWBXKKVVaC9w/BcPnGuSRy OZTyPg==
> 
> ;; AUTHORITY SECTION:
> eeoc.gov.   66519   IN  NS  dnssec10.datamtn.com.
> eeoc.gov.   66519   IN  NS  dnssec14.datamtn.com.
> eeoc.gov.   66519   IN  NS  dnssec11.datamtn.com.
> eeoc.gov.   66519   IN  NS  dnssec12.datamtn.com.
> eeoc.gov.   66519   IN  NS  dnssec9.datamtn.com.
> 
> ;; ADDITIONAL SECTION:
> dnssec9.datamtn.com.3114IN  2001:49f0:a02a:1000::238
> dnssec11.datamtn.com.   3114IN  2001:470:1:7a::147
> dnssec9.datamtn.com.3114IN  RRSIG    7 3 10800 2025185428 
> 20110827185428 21352 datamtn.com. 
> Ngz7Bl2VWqhIY5Uh8bHJjwyAWQXcEM7qaAH8JSJ5VM5qMelfVA1pV+Y6 
> RltfXpACQxRpHsayiArGZulzp1XX4yW6+qsHiKLJOcRiS5kmjexBPUlK 
> zyU3cp7BC5dprHyPBpXKbHExuGlvqrg1aqRJtAmH6Q7tkp2wWqEuO3Ku 
> LBvvGXN46U+sYPsd98YixlLLTtj2qFo7/vhPN8ao2g6HuFBVIUTU4LuV 
> d7Wjz+r4Xj722w6RFgZFu9qFwYsOQwTGlon4zqDvflzESSWSjFdzHCZ0 
> prkagjXwcZYMlQGRMgnmHlEEvvg+lKMdl4imHLx/LKLD+feCzp2d4PFj 9byoYA==
> dnssec9.datamtn.com.3114IN  RRSIG    8 3 10800 2025185428 
> 20110827185428 61898 datamtn.com. 
> NtPfKvEs6DF0Bac9ZbCfi0b0QdeVMSlaNXAyDFSjo4J8uQUYllDwt101 
> C78VAiXplumZRM/9Vv7fg1/Ds/qCd6wC6wdTR3S8mtDOpLHVhuZTSGI1 
> jBVBXYjzBdqIBitydwD6vs+VaPsfd352NBqE8teFQJhbVAI98+d9BO4x 
> /Qx+i2HJOPdQyVRq6dj2NYg1GT4ODDb6VmQUOb01XgIyX/pLt+7AdtId 
> 1FFbA9LfO4xvYTCKAO3LbPvdU7nJ2+mCMu5CNQFNiwAbSHT3letupzpH 
> yLUNrjhcO0cj/vVf1YrrIzZXF69zKGYfsCP876zKoVtlrUe1dZ0bersP 4I9klg==
> dnssec11.datamtn.com.   3114IN  RRSIG    7 3 10800 2025185428 
> 20110827185428 21352 datamtn.com. 
> Lgt6Wq5JvvAF6BKUUoPSiv6lx0yqQ3HAFoClEcg11V7XhIngeaTperu7 
> 7lytmKl53yZUxarFbQdJ/NxwwNVl/F2Os5RkNHkAjVTkku1mjoMeqEhF 
> NDe+cvYOOo0EASc9LhmHo2qgkyhjGAt1FtbmrOG9Gwr5OdUM5l2EgcGj 
> bRvH1Sfv5le68ST1+74sQPKmp+3n0gopfKUlcYuDDw/mUKXR8lo3MCTv 
> xe6q6NbwHNHWBCgUw4rqX4ZdVArL4WumKvkufeieDJpMhKwHlWHyPvu9 
> pX1IsZRyQPo9RqnmSpG+yjR59ixbb23LyO6alrEDJTyaJZL8uHfwiTQ8 4V29tQ==
> dnssec11.datamtn.com.   3114IN  RRSIG    8 3 10800 2025185428 
> 20110827185428 61898 datamtn.com. 
> vtFFEZbruIfnwSGAdlXukUn40SOEIZY9QXrHh6CfOl3WkQduSnbvgS5T 
> +e2QN6GDcZgigGON8yHHTS8DI8ld/tCxxVkwB3ISkqkQHrjyyRD6+8IR 
> J2BWsdMTyAhe9PygLR1FkfCt1JDaDnAbOKOniMT+6DRlnE7ZW7KfvZT/ 
> 7j5qG+xDixCXUHyhnstbv9vmMPTxnK1ASy6nz7ErnA/DUMleO484xIgM 
> 6Pc8uqy3Onw4Yfn4l5R66tQwC0yoSVwqmEyIWNWyx1SNQLFzUc1hySaF 
> aQs1L/Zyu9e/wSHdZUeGiOwx5cz3yWE2NsF3tagxukkL9vNu2s/nyjzR 3igT3g==
> 
> ;; Query time: 1 msec
> ;; SERVER: 10.120.11.107#53(10.120.11.107)
> ;; WHEN: Tue Sep 27 15:34:07 2011
> ;; MSG SIZE  rcvd: 1726
> 
> 
> Which tells me my DNSSEC queries are working, right?
> I noticed in the "OPT PSEUDOSECTION" udp=4096.
> 
> This started because, as the DNS admin, I was informed today that we could 
> not resolve
> this domain, eeoc.gov. Which was true. As I started digging into it, and 
> performing a
> dig from an offsite server which was working, I found that the domain 
> "eeoc.gov" is 
> running DNSSEC. So, I assumed the problem was with our firewall blocking or 
> filtering
> the DNSSEC traffic. But then after researching for a few hours, I found we 
> w

Re: Max number of views and performance.

[Steve Arntzen]

It is my experience the client hits the views in order (top, down) until
an ACL allows it.  Once an ACL allows it in a view, it goes no further.

Steve.



On Wed, 2011-08-24 at 10:32 -0300, sky shade wrote:
> Someone know how bind test client matches? I know that its respect the
> declaration sequence, but i dont know if they will test matches in all
> views before goes to default.
> 
> On Wed, Aug 24, 2011 at 3:53 AM, Alans  wrote:
> BIND loads all views to memory, with that number you will run
> into memory problems.
> 
> regards,
> Alans
> 
> 
> On 8/24/2011 7:04 AM, sky shade wrote:
> 
> 
> Hello
> 
> I like to know if bind 9.8 have a limit of view?
> There is any number or I can create something like 1
> million views without problems?
> There is any performance implication in use to many
> views?
> 
> Thanks
> 
> Skyshade
> 
> 
> 
> 
> 
> ___
> Please visit
> https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users
> to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems in views in a zone transfer

[Steve Arntzen]

I've been using multiple views and servers successfully for a while now.
I hope the following helps...

To transfer zones to and from specific views, you can use keys,
"match-clients" and "server" declarations to control access and
transfers.

Setup keys for each view.

Disallow clients (and servers) without those keys in the inappropriate
views.

Allow clients (and servers) with those keys in the appropriate view.

Remember, the views are hit in top, down order.  By default, your slaves
will all hit the first view.  Whoever you don't want in the upper views,
you must specifically block from those views and allow them later in a
other view.

Increasing log levels and viewing logs will tell you what's going on.

Good luck,

Steve.


Assuming 192.168.100.5 is your master and 192.168.100.10 and
192.168.100.20 are your slaves:
--

On the master:

view "VIEW1" {
match-clients {
!key VIEW2;   // Block VIEW2 from slave to this view
!key VIEW3;   // Block VIEW3 from slave to this view
"any";// Allow anyone else in this view
};

allow-transfer { 192.168.100.10; 192.168.100.20; };

server 192.168.100.10 {keys VIEW1; };   // first slave
server 192.168.100.20 {keys VIEW1; };   // second slave

...rest of view...
};


view "VIEW2" {
match-clients {
!key VIEW1;   // Block VIEW1 from slave to this view
!key VIEW3;   // Block VIEW3 from slave to this view
};

allow-transfer { 192.168.100.10; 192.168.100.20; };

server 192.168.100.10 {keys VIEW2; };   // first slave
server 192.168.100.20 {keys VIEW2; };   // second slave

...rest of view...
};

view "VIEW3" {
match-clients {
!key VIEW1;   // Block VIEW1 from slave to this view
!key VIEW2;   // Block VIEW2 from slave to this view
};

allow-transfer { 192.168.100.10; 192.168.100.20; };

server 192.168.100.10 {keys VIEW3; };   // first slave
server 192.168.100.20 {keys VIEW3; };   // second slave

...rest of view...
};

--

On the slave(s):

view "VIEW1" {

match-clients {
   192.168.100.0/24;  // IPs you want to access this view
  // Note: you must include the IP of
  // the master to receive notifications.
   };
 
server 192.168.100.5 {keys VIEW1; };   // master

...rest of view...

};


view "VIEW2" {

match-clients {
192.168.200.0/24;  // IPs you want to access this view
192.168.100.5; // IP of master for notifications
};
 
server 192.168.100.5 {keys VIEW2; };   // master

...rest of view...

};


Etc.

---


On Tue, 2011-05-10 at 17:03 +0200, Matus UHLAR - fantomas wrote:
> > On Tue, May 10, 2011 at 2:50 PM, Luis Silva  wrote:
> > > Many thanks for the answer. Btw, If I want to notify the slaves that a 
> > > zone
> > > is updated, which parameter (ip:port) needs to be configured in the slave 
> > > to
> > > differenciate the view? Is the "transfer-source" also used for listening 
> > > for
> > > the notify requests?
> 
> On 10.05.11 15:39, Luis Silva wrote:
> > Let me refrase my question. How can I notify a slave that suports different
> > views for the zone? How can the master distinguish?
> 
> master can not distinguish the slaves when sending notify. It can only send
> the notify to slaves... If you have multiple views on the slave containing
> the same zone, you must either give them different IP and send notify to
> both IPs or you can configure one view to fetch the zone from master and
> notify the second view, which will fetch the zone from master or the first
> view.
> 

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slaves and views

[Steve Arntzen]

On Fri, 2011-03-04 at 11:46 -0500, John Wobus wrote:
> Hi,
> 
> Can a zone file a slave in one view and the same zone file
> be served by another view?

It is a bad idea, although I know (from experience) it will work for
static zones.  One problem is you need to remember to reload the zone in
both views if you make any changes to it.

Again, it is a bad idea and I think ISC recommends against it.


> I'm not (yet) worried about dynamic updates, if there are
> any.

That will not work.  You will need separate files for each view.

Steve.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multi-master with mysql backend

[Steve Arntzen]

>>> I need really something very simple:
>>>
>>>
>>> I have 2 domain name servers, I need them to be multi-master
>> Please explain -- *why* do you need multimaster?
>>
>>
>I need to be able to update the nameserver even if one of the two 
>masters is down, I need this
>for High Avaliability purposes for services geographycally distriuted

>If I do not have a multimaster architecture and primary nameserver
>goes 
>down, I Cannot update the secondary
>if I need to.



How about rsync?

I too need a second master in an alternate location, only in the event
of a catastrophe (loss of a data center).  There are active slaves with
dynamic zones in both locations.  Any of the slaves can use either
master, but by default, they use the one listed first in named.conf
which is the master in the main location.  If the first master
disappears, the slaves will use the other master.

Simplicity is important to me as well and that's why I chose rsync to
periodically get the zone data (and configs) to the master in the
secondary location.  I looked into MySQL (which I use for other
purposes), but the solution was no longer simple.

Steve.




___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: transfer with views

[Steve Arntzen]

Have you looked at the logs?

You may need to change the debug level with rndc.  You can also set it
when starting bind - named -d debug-level.

Debug level 5 - "Captures the view being used in order to answer a
request".

Have you verified the two views which are being transferred to make sure
they are correct?  If the configuration isn't correct, the same zone can
be transferred to multiple views.

If you are successfully transferring multiple views, can you post the
slave configuration?  Is the slave using the correct key in the third
view?

Steve.


On Sat, 2011-01-01 at 19:13 +0800, p...@mail.nsbeta.info wrote:
> Two bind servers, one master, one slave.
> There are three views at each.
> The config is shown below.
> But why the first two veiws can get transfered, the third can't be transfer? 
> 
> Thanks in advance. 
> 
>  -
> master: 
> 
> options {
> directory "/usr/local/named/var/named";
> }; 
> 
> key "rndc-key" {
> algorithm hmac-md5;
> secret "WcdaZV54M3k7w6c71DDljg==";
> }; 
> 
> controls {
> inet 127.0.0.1 port 953
> allow { 127.0.0.1; } keys { "rndc-key"; };
> }; 
> 
> key liantong-key {
> algorithm hmac-md5;
> secret "a85qJDXsRKimmutrmrFw3Q==";
> }; 
> 
> key dianxin-key {
> algorithm hmac-md5;
> secret "M5i0sjb6b9pA0NvTqp8+GA==";
> }; 
> 
> key any-key {
> algorithm hmac-md5;
> secret "fxe5wmufv275rD029312og==";
> }; 
> 
> include "/usr/local/named/var/named/liantong.acl";
> include "/usr/local/named/var/named/dianxin.acl"; 
> 
>  
> 
> view "liantong" {
>match-clients {key liantong-key;liantong;};
>recursion yes;
>allow-transfer {key liantong-key;};
>server 192.168.1.202 {keys liantong-key;};
>  zone "." IN {
>type hint;
>file "named.root";
>};
>  zone "luwenju.com" IN {
>type master;
>file "liantong.luwenju.com.zone";
>};
>}; 
> 
> view "dianxin" {
>match-clients {key dianxin-key;dianxin;};
>recursion yes;
>allow-transfer {key dianxin-key;};
>server 192.168.1.202 {keys dianxin-key;};
>  zone "." IN {
>type hint;
>file "named.root";
>};
>  zone "luwenju.com" IN {
>type master;
>file "dianxin.luwenju.com.zone";
>};
>}; 
> 
> view "any" {
>match-clients {key any-key;any;};
>recursion yes;
>allow-transfer {key any-key;};
>server 192.168.1.202 {keys any-key;};
>  zone "." IN {
>type hint;
>file "named.root";
>};
>  zone "luwenju.com" IN {
>type master;
>file "any.luwenju.com.zone";
>};
>}; 
> 
>  - 
> 
> slave: 
> 
> options {
> directory "/usr/local/named/var/named";
> }; 
> 
> key "rndc-key" {
> algorithm hmac-md5;
> secret "WcdaZV54M3k7w6c71DDljg==";
> }; 
> 
> controls {
> inet 127.0.0.1 port 953
> allow { 127.0.0.1; } keys { "rndc-key"; };
> }; 
> 
> key liantong-key {
> algorithm hmac-md5;
> secret "a85qJDXsRKimmutrmrFw3Q==";
> }; 
> 
> key dianxin-key {
> algorithm hmac-md5;
> secret "M5i0sjb6b9pA0NvTqp8+GA==";
> }; 
> 
> key any-key {
> algorithm hmac-md5;
> secret "fxe5wmufv275rD029312og==";
> }; 
> 
> include "/usr/local/named/var/named/liantong.acl";
> include "/usr/local/named/var/named/dianxin.acl"; 
> 
> 
> view "liantong" {
>match-clients {key liantong-key;liantong;};
>recursion yes;
>allow-transfer {key liantong-key;};
>server 192.168.1.201 {keys liantong-key;};
>  zone "." IN {
>type hint;
>file "named.root";
>};
>  zone "luwenju.com" IN {
>type slave;
>masters {192.168.1.201;};
>file "liantong.luwenju.com.zone";
>};
>}; 
> 
> view "dianxin" {
>match-clients {key dianxin-key;dianxin;};
>recursion yes;
>allow-transfer {key dianxin-key;};
>server 192.168.1.201 {keys dianxin-key;};
>  zone "." IN {
>type hint;
>file "named.root";
>};
>  zone "luwenju.com" IN {
>type slave;
>masters {192.168.1.201;};
>file "dianxin.luwenju.com.zone";
>};
>}; 
> 
> view "any" {
>match-clients {key any-key;any;};
>recursion yes;
>allow-transfer {key any-key;};
>server 192.168.1.201 {keys any-key;};
>  zone "." IN {
>type hint;
>file "named.root";
>};
>  zone "luwenju.com" IN {
>type slave;
>masters {192.168.1.201;};
>file "any.luwenju.com.zone";
>};
>};
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
bind-users mailing li

Re: bind replication

[Steve Arntzen]

> Done carefully (which will be the case in all circumstances), doing zone
> transfers within views of many zones is no more "likely to get broken"
> than doing it with external mechanisms.
> 
> Been there, done that, have the tee-shirt and certainly don't want to
> use rsync.
> 
> AlanC
> 

I wanted to reply to this earlier.

I have several zones, five views and multiple slaves which pick up zone
data from specific views.  Add to that some dynamic zones.

Because the named.conf file became not only complex, but also large, I
ended up breaking the configuration into multiple files (options, views
and zone declarations) and using include statements to tie it all
together.  That made the configuration much easier to read and
understand.

Bind does everything at the local site itself without issue.  Any zone
data changes are made on the master and everything syncs up.  It just
works (like it's supposed to).

I use rsync ONLY to copy the configuration and zone data to a remote
site for disaster recovery every thirty minutes.  rsync is configured to
NOT copy the journal files.  As Bind will periodically write out the
journaled data, the zone data at the remote site is pretty fresh.

One downside to rsync is having to be aware of when the scheduled
synchronization occurs.  One must be careful when editing zone files or
changing configurations so that partial changes are not copied to the
remote systems which could cause problems.

Let Bind do it's thing.

My 2 cents,

Steve.

> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named won't restart

[Steve Arntzen]

Is it possible named was killed and restarted without
the /etc/init.d/named script?

The script looks up the process ID from /var/run/bind/run/named.pid (on
Debian) and if the PID doesn't match, the script can't stop named.

You can cat /var/run/bind/run/named.pid and compare the PID to what you
see in the process table.  If you stop bind and restart it with the init
script the PID should match and "restart" should work after that.

Steve.



On Fri, 2010-11-12 at 14:00 +0200, Bèrto ëd Sèra wrote:
> maybe this can be of help:
> http://bugs.gentoo.org/show_bug.cgi?id=324315
> 
> On 11 November 2010 20:49, Carlos Vicente
>  wrote:
> Has anybody had this problem?
> 
> # /etc/init.d/named restart
> Stopping named: .
>  [FAILED]
> Starting named: named: already running
> [  OK  ]
> 
> I notice it happens after the daemon has been running for a
> while. If I
> kill it and start it again, then restart works OK.
> 
> This is a caching resolver, with dnssec validation enabled.
> 
> # cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
> 
> 
> # named -V
> BIND 9.7.1-P2-RedHat-9.7.1-5.P2.uopel5 built with
> '--build=x86_64-redhat-linux-gnu'
> '--host=x86_64-redhat-linux-gnu'
> '--target=x86_64-redhat-linux-gnu' '--program-prefix='
> '--prefix=/usr'
> '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
> '--sysconfdir=/etc' '--datadir=/usr/share'
> '--includedir=/usr/include'
> '--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
> '--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
> '--infodir=/usr/share/info' '--with-libtool'
> '--localstatedir=/var'
> '--enable-threads' '--enable-ipv6' '--with-pic'
> '--disable-static'
> '--disable-openssl-version-check' '--with-gssapi=yes'
> '--disable-isc-spnego' 'build_alias=x86_64-redhat-linux-gnu'
> 'host_alias=x86_64-redhat-linux-gnu'
> 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe
> -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS=
> -DDIG_SIGCHASE' 'CXXFLAGS=-O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic' 'FFLAGS=-O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic'
> 
> 
> Thanks in advance for any pointers.
> 
> cv
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> -- 
> ==
> Constitution du 24 juin 1793 - Article 35. - Quand le gouvernement
> viole les droits du peuple, l'insurrection est, pour le peuple et pour
> chaque portion du peuple, le plus sacré des droits et le plus
> indispensable des devoirs.
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Multiple CNAME alternantive?

[Steve Arntzen]

I would like to resolve dns.ourdomain.com to a list of our DNS server
names and possibly their IPs.

As we use many DNS servers (and or views) for our different development
environments, it would be very helpful for the developers to easily find
the name and IP of the proper name server to use.

EXAMPLE:

A lookup for dns.ourdomain.com would result in:

nsdev1.ourdomain.com192.168.100.10
nsdev2.ourdomain.com192.168.100.11
nstest1.ourdomain.com   192.168.100.12
nstest2.ourdomain.com   192.168.100.13
nsprod1.ourdomain.com   192.168.100.14
nsprod2.ourdomain.com   192.168.100.15
etc.

I want to avoid using configuration exceptions and multiple CNAMEs.
Does anyone have a "clean" alternative?

Thanks,

Steve.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users