Re: Disable log message
On 10/19/2012 11:57 PM, Chris Buxton wrote: > On Oct 19, 2012, at 6:22 PM, Warren Kumari wrote: >> On Oct 19, 2012, at 9:17 PM, "Michael Hoskins (michoski)" >> wrote: >>> -Original Message- On Oct 19, 2012, at 6:13 PM, Alan Clegg wrote: > > On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: > >> On Oct 18 2012, Jeremy C. Reed wrote: >> >>> On Thu, 18 Oct 2012, Jack Tavares wrote: >>> I am running bind9.8.x built from source and I see this message in the logs built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' '--mandir=/usr/share/man' '--with-openssl=/blah' '--enable-fixed-rrset' '--enable-shared' '--enable-threads' '--enable-ipv6' '--with-libtool' etc etc etc I would prefer to not have that show up in the log. Short of modifying the source, is there an easy way to disable that? >>> >>> No way to disable just it. It is in the "general" catch-all category. >> >> Also, it is output before the configuration "logging" directives have >> been >> processed, so it comes out with the internal defaults for category and >> priority (daemon.notice). Any suppression would need to be done at the >> syslog level. >> >> But I have some difficulty understanding why anyone would want it >> suppressed. >> It's true that BIND is a bit noisier than it used to be at this stage, >> but >> can this really be a problem? Do you let the black hats see your >> system logs? > > > This message was added by general recognition that being able to > rebuild a "drop-in" binary for BIND when you didn't have access to the > build directory (where the config.log contains the information) was a > good thing. Yah, a very good thingŠ This has been really really useful to me on a number of occasionsŠ > > I, for one, see no reason to suppress this message (but I do have blind > spots at times). Me neither, but I am interested why folk might want toŠ >>> >>> Maybe it's viewed as information disclosure? >> >> Ah, that's a good point, especially if BIND is being incorporated into an >> appliance / black box and there is no need for the users of the appliance to >> know what all goes on under the hood? > > An an employee of the maker of an appliance solution, I can say that we > gladly tell our customers what's going on under the hood. If we didn't, they > wouldn't trust us. Does this log message provide any information that the -V option doesn't provide? $ named -V BIND 9.8.0-P4 built with '--prefix=/blah' '--exec-prefix=/blah' '--enable-threads' '--enable-ipv6' 'CFLAGS=-O2 -march=native ...and so on... using OpenSSL version: OpenSSL 1.0.0d 8 Feb 2011 using libxml2 version: 2.7.8 -DMM ___ 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: Disable log message
On Oct 19, 2012, at 6:22 PM, Warren Kumari wrote: > On Oct 19, 2012, at 9:17 PM, "Michael Hoskins (michoski)" > wrote: >> -Original Message- >>> On Oct 19, 2012, at 6:13 PM, Alan Clegg wrote: >>> On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: > On Oct 18 2012, Jeremy C. Reed wrote: > >> On Thu, 18 Oct 2012, Jack Tavares wrote: >> >>> I am running bind9.8.x built from source and I see this message in >>> the logs >>> built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' >>> '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' >>> '--mandir=/usr/share/man' '--with-openssl=/blah' >>> '--enable-fixed-rrset' '--enable-shared' '--enable-threads' >>> '--enable-ipv6' '--with-libtool' etc etc etc I would prefer to not >>> have that show up in the log. >>> Short of modifying the source, is there an easy way to disable that? >> >> No way to disable just it. It is in the "general" catch-all category. > > Also, it is output before the configuration "logging" directives have > been > processed, so it comes out with the internal defaults for category and > priority (daemon.notice). Any suppression would need to be done at the > syslog level. > > But I have some difficulty understanding why anyone would want it > suppressed. > It's true that BIND is a bit noisier than it used to be at this stage, > but > can this really be a problem? Do you let the black hats see your > system logs? This message was added by general recognition that being able to rebuild a "drop-in" binary for BIND when you didn't have access to the build directory (where the config.log contains the information) was a good thing. >>> >>> Yah, a very good thingŠ This has been really really useful to me on a >>> number of occasionsŠ >>> I, for one, see no reason to suppress this message (but I do have blind spots at times). >>> >>> Me neither, but I am interested why folk might want toŠ >> >> Maybe it's viewed as information disclosure? > > Ah, that's a good point, especially if BIND is being incorporated into an > appliance / black box and there is no need for the users of the appliance to > know what all goes on under the hood? An an employee of the maker of an appliance solution, I can say that we gladly tell our customers what's going on under the hood. If we didn't, they wouldn't trust us. Chris Buxton BlueCat Networks ___ 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: Disable log message
On Oct 19, 2012, at 9:17 PM, "Michael Hoskins (michoski)" wrote: > -Original Message- > > From: Warren Kumari > Date: Friday, October 19, 2012 8:56 PM > To: Alan Clegg > Cc: "bind-us...@isc.org" > Subject: Re: Disable log message > >> >> On Oct 19, 2012, at 6:13 PM, Alan Clegg wrote: >> >>> >>> On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: >>> On Oct 18 2012, Jeremy C. Reed wrote: > On Thu, 18 Oct 2012, Jack Tavares wrote: > >> I am running bind9.8.x built from source and I see this message in >> the logs >> built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' >> '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' >> '--mandir=/usr/share/man' '--with-openssl=/blah' >> '--enable-fixed-rrset' '--enable-shared' '--enable-threads' >> '--enable-ipv6' '--with-libtool' etc etc etc I would prefer to not >> have that show up in the log. >> Short of modifying the source, is there an easy way to disable that? > > No way to disable just it. It is in the "general" catch-all category. Also, it is output before the configuration "logging" directives have been processed, so it comes out with the internal defaults for category and priority (daemon.notice). Any suppression would need to be done at the syslog level. But I have some difficulty understanding why anyone would want it suppressed. It's true that BIND is a bit noisier than it used to be at this stage, but can this really be a problem? Do you let the black hats see your system logs? >>> >>> >>> This message was added by general recognition that being able to >>> rebuild a "drop-in" binary for BIND when you didn't have access to the >>> build directory (where the config.log contains the information) was a >>> good thing. >> >> Yah, a very good thingŠ This has been really really useful to me on a >> number of occasionsŠ >> >>> >>> I, for one, see no reason to suppress this message (but I do have blind >>> spots at times). >> >> Me neither, but I am interested why folk might want toŠ > > Maybe it's viewed as information disclosure? Ah, that's a good point, especially if BIND is being incorporated into an appliance / black box and there is no need for the users of the appliance to know what all goes on under the hood? W > It's always good to give > folks a choice -- what's useful for some (or others, like me, don't care > about at all) will be annoying to others. > -- "Go on, prove me wrong. Destroy the fabric of the universe. See if I care." -- Terry Prachett ___ 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: Disable log message
-Original Message- From: Warren Kumari Date: Friday, October 19, 2012 8:56 PM To: Alan Clegg Cc: "bind-us...@isc.org" Subject: Re: Disable log message > >On Oct 19, 2012, at 6:13 PM, Alan Clegg wrote: > >> >> On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: >> >>> On Oct 18 2012, Jeremy C. Reed wrote: >>> On Thu, 18 Oct 2012, Jack Tavares wrote: > I am running bind9.8.x built from source and I see this message in >the logs > built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' >'--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' >'--mandir=/usr/share/man' '--with-openssl=/blah' >'--enable-fixed-rrset' '--enable-shared' '--enable-threads' >'--enable-ipv6' '--with-libtool' etc etc etc I would prefer to not >have that show up in the log. > Short of modifying the source, is there an easy way to disable that? No way to disable just it. It is in the "general" catch-all category. >>> >>> Also, it is output before the configuration "logging" directives have >>>been >>> processed, so it comes out with the internal defaults for category and >>> priority (daemon.notice). Any suppression would need to be done at the >>> syslog level. >>> >>> But I have some difficulty understanding why anyone would want it >>>suppressed. >>> It's true that BIND is a bit noisier than it used to be at this stage, >>>but >>> can this really be a problem? Do you let the black hats see your >>>system logs? >> >> >> This message was added by general recognition that being able to >>rebuild a "drop-in" binary for BIND when you didn't have access to the >>build directory (where the config.log contains the information) was a >>good thing. > >Yah, a very good thingŠ This has been really really useful to me on a >number of occasionsŠ > >> >> I, for one, see no reason to suppress this message (but I do have blind >>spots at times). > >Me neither, but I am interested why folk might want toŠ Maybe it's viewed as information disclosure? It's always good to give folks a choice -- what's useful for some (or others, like me, don't care about at all) will be annoying to others. ___ 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: Disable log message
On Oct 19, 2012, at 6:13 PM, Alan Clegg wrote: > > On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: > >> On Oct 18 2012, Jeremy C. Reed wrote: >> >>> On Thu, 18 Oct 2012, Jack Tavares wrote: >>> I am running bind9.8.x built from source and I see this message in the logs built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' '--mandir=/usr/share/man' '--with-openssl=/blah' '--enable-fixed-rrset' '--enable-shared' '--enable-threads' '--enable-ipv6' '--with-libtool' etc etc etc I would prefer to not have that show up in the log. Short of modifying the source, is there an easy way to disable that? >>> >>> No way to disable just it. It is in the "general" catch-all category. >> >> Also, it is output before the configuration "logging" directives have been >> processed, so it comes out with the internal defaults for category and >> priority (daemon.notice). Any suppression would need to be done at the >> syslog level. >> >> But I have some difficulty understanding why anyone would want it suppressed. >> It's true that BIND is a bit noisier than it used to be at this stage, but >> can this really be a problem? Do you let the black hats see your system logs? > > > This message was added by general recognition that being able to rebuild a > "drop-in" binary for BIND when you didn't have access to the build directory > (where the config.log contains the information) was a good thing. Yah, a very good thing… This has been really really useful to me on a number of occasions… > > I, for one, see no reason to suppress this message (but I do have blind spots > at times). Me neither, but I am interested why folk might want to… W > > AlanC > -- > Alan Clegg | +1-919-355-8851 | a...@clegg.com > > > > > > ___ > 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 -- Consider orang-utans. In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment. -- Terry Practhett ___ 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: transparent DNS load-balancing with a Cisco ACE
-Original Message-
From: Chuck Swiger
Date: Friday, October 19, 2012 5:09 PM
To: John Miller
Cc: DNS BIND
Subject: Re: transparent DNS load-balancing with a Cisco ACE
>>
>> We're on a /16, so we have plenty of public IPs (though not as many as
>>you!) to play with, too. The choice to NAT has historically been more
>>about security than anything else--if something is privately IPed, we've
>>got it on a special VLAN as well.
>
>OK. I've seen too many examples of traffic leaking between VLANs to
>completely trust their isolation, but good security ought to involve many
>layers which don't have to each be perfect to still provide worthwhile
>benefits.
"NAT is not a security mechanism" :-)
>>If that's the case, how do you keep your probes (to the IP behind the
>>LB) working, while still sending back regular DNS traffic (that was
>>originally sent to the virtual IP) with the VIP as a source address?
>>Seems like you get only one or the other unless you tweak
>>iptables/ipfw/etc.
>
>There are two types of probes that I'm familiar with.
>
>One involves liveness probes between the LB itself to the reals, which is
>done so that the LB can decide which of the reals are available and
>should be getting traffic. For these, the reals are replying using their
>own IPs. The other type of probe is to the VIP; the LB forwards traffic
>to the reals, gets a reply, and then proxies or rewrites these responses
>and returns them to the origin of the probe using the IP of the VIP. Or
>you can short-cut replies going back via the LB using DSR ("Direct
>Service Return"), or whatever your LB vendor calls that functionality...
>
>All of your normal clients would only be talking to the VIP, and would
>only see traffic coming from the VIP's IP.
Hmm, I must have got lucky or this is being over-thought... I use ACE
with Linux/BIND reals and DSR. No problems with traffic or probes. I
would avoid NAT for DNS. It's certainly possible, though NDAs avoid
copy/paste. :-(
Ugly URLs suck almost as much as NDAs:
http://docwiki.cisco.com/wiki/Cisco_Application_Control_Engine_%28ACE%29_Co
nfiguration_Examples_--_Server_Load-Balancing_Configuration_Examples#Exampl
e_of_a_UDP_Probe_Load-Balancing_Configuration
Better:
https://lists.isc.org/pipermail/bind-users/2012-March/087105.html
While you're at it, test your fixups... :-)
https://www.dns-oarc.net/oarc/services/replysizetest/
Good luck!
___
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: Disable log message
While I can see maybe not being interested, caring enough to supress it has me curious. - Original Message - From: Alan Clegg [mailto:a...@clegg.com] Sent: Friday, October 19, 2012 06:13 PM To: bind-us...@isc.org Subject: Re: Disable log message On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: > On Oct 18 2012, Jeremy C. Reed wrote: > >> On Thu, 18 Oct 2012, Jack Tavares wrote: >> >>> I am running bind9.8.x built from source and I see this message in the logs >>> built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' >>> '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' >>> '--mandir=/usr/share/man' '--with-openssl=/blah' '--enable-fixed-rrset' >>> '--enable-shared' '--enable-threads' '--enable-ipv6' '--with-libtool' etc >>> etc etc I would prefer to not have that show up in the log. >>> Short of modifying the source, is there an easy way to disable that? >> >> No way to disable just it. It is in the "general" catch-all category. > > Also, it is output before the configuration "logging" directives have been > processed, so it comes out with the internal defaults for category and > priority (daemon.notice). Any suppression would need to be done at the > syslog level. > > But I have some difficulty understanding why anyone would want it suppressed. > It's true that BIND is a bit noisier than it used to be at this stage, but > can this really be a problem? Do you let the black hats see your system logs? This message was added by general recognition that being able to rebuild a "drop-in" binary for BIND when you didn't have access to the build directory (where the config.log contains the information) was a good thing. I, for one, see no reason to suppress this message (but I do have blind spots at times). AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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: Disable log message
On Oct 18, 2012, at 1:13 PM, Chris Thompson wrote: > On Oct 18 2012, Jeremy C. Reed wrote: > >> On Thu, 18 Oct 2012, Jack Tavares wrote: >> >>> I am running bind9.8.x built from source and I see this message in the logs >>> built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' >>> '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' >>> '--mandir=/usr/share/man' '--with-openssl=/blah' '--enable-fixed-rrset' >>> '--enable-shared' '--enable-threads' '--enable-ipv6' '--with-libtool' etc >>> etc etc I would prefer to not have that show up in the log. >>> Short of modifying the source, is there an easy way to disable that? >> >> No way to disable just it. It is in the "general" catch-all category. > > Also, it is output before the configuration "logging" directives have been > processed, so it comes out with the internal defaults for category and > priority (daemon.notice). Any suppression would need to be done at the > syslog level. > > But I have some difficulty understanding why anyone would want it suppressed. > It's true that BIND is a bit noisier than it used to be at this stage, but > can this really be a problem? Do you let the black hats see your system logs? This message was added by general recognition that being able to rebuild a "drop-in" binary for BIND when you didn't have access to the build directory (where the config.log contains the information) was a good thing. I, for one, see no reason to suppress this message (but I do have blind spots at times). AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com smime.p7s Description: S/MIME cryptographic signature ___ 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: ISC Bind in Active Directory
On Oct 19, 2012, at 13.27, Phil Mayers wrote: > Nicholas F Miller wrote: > >> DDNS record scavenging is the only feature I'm aware of that MS DNS has >> that Bind doesn't . On the flip side, ISC Bind can ACL who can add >> certain record types to a dynamic zone using GSS-TSIG as well as >> supports views and ACLs for recursion. Everything else should be >> standard DNS. >> > > Yeah, that would be nice to have actually. More generally, metadata on ddns > records would be useful. to be honest, this doesn't seem to me to be something that would fall within bind's purview. comparing bind to "microsoft dns" isn't really apples to apples. microsoft dns is more than just a dns server. it's also a dns management system [whereas bind is not], which is where things like scavenging dns data or publishing metadata would belong. one partial example of this would be dhcpd's use of ddns, which uses txt records to include some metadata in dns.as it is, bind can fully support probably any such mechanism, with the benefit of being agnostic. i like that modularity, and would be disappointed if it changed. -b ___ 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: transparent DNS load-balancing with a Cisco ACE
Hi--
On Oct 19, 2012, at 1:04 PM, John Miller wrote:
>> IMO, the only boxes which should have IPs in both public and private
>> netblocks should be your firewall/NAT routing boxes.
>
> That's how we usually have our servers set up--the load balancer gets the
> public IPs, the servers get the private IPs, and we use NAT to translate
> between the two.
OK.
>>> Here's a question, however: how does one get probes working for a
>>> transparent LB setup? If an rserver listens for connections on all
>>> interfaces, then probes work fine, but return traffic from the uses the
>>> machine's default IP (not the VIP that was originally queried) for the
>>> source address of the return traffic.
>>
>> That's the default routing behavior for most platforms. Some of them might
>> support some form of policy-based routing via ipfw fwd / route-to or similar
>> with other firewall mechanisms which would let the probes get returned from
>> some other source address if you want them to do so.
>
> Good to know--you'd definitely expect traffic to come back on the main
> interface. I've considered setting up some iptables rules to make this
> happen, but if I can avoid it, so much the better. Sounds like this is what
> I need to do, however, if I want both probes and regular requests to work.
Perhaps I misunderstand, but if the internal boxes only have one IP, how can
they not be using the right source address when replying to liveness probes
from your LB or some other monitor? Do you probe on an external IP and have
something else doing NAT besides the LB itself?
Or do you setup a second IP on your reals which is what the LB sends traffic to?
(That's kinda what your lo:1 entry of 129.64.x.53 looked like.)
>>> What have people done to get probes working with transparent LB? Are any
>>> of you using NAT to handle your dns traffic? Not tying up NAT tables seems
>>> like the way to go, but lack of probes is a deal-breaker on this end.
>>
>> The locals around here have the luxury of a /8 netblock, so they can setup
>> the reals behind a LB using publicly routable IPs and never need to NAT upon
>> DNS traffic. Folks with more limited # of routable IPs might well use LB to
>> reals on an unrouteable private network range behind NAT, but in which case
>> they wouldn't configure those boxes with public IPs.
>
> We're on a /16, so we have plenty of public IPs (though not as many as you!)
> to play with, too. The choice to NAT has historically been more about
> security than anything else--if something is privately IPed, we've got it on
> a special VLAN as well.
OK. I've seen too many examples of traffic leaking between VLANs to completely
trust their isolation, but good security ought to involve many layers which
don't have to each be perfect to still provide worthwhile benefits.
> Presumably those reals are still behind a virtual ip address that's also
> public, right?
Yes, presumably. :)
> If that's the case, how do you keep your probes (to the IP behind the LB)
> working, while still sending back regular DNS traffic (that was originally
> sent to the virtual IP) with the VIP as a source address? Seems like you get
> only one or the other unless you tweak iptables/ipfw/etc.
There are two types of probes that I'm familiar with.
One involves liveness probes between the LB itself to the reals, which is done
so that the LB can decide which of the reals are available and should be
getting traffic. For these, the reals are replying using their own IPs. The
other type of probe is to the VIP; the LB forwards traffic to the reals, gets a
reply, and then proxies or rewrites these responses and returns them to the
origin of the probe using the IP of the VIP. Or you can short-cut replies
going back via the LB using DSR ("Direct Service Return"), or whatever your LB
vendor calls that functionality...
All of your normal clients would only be talking to the VIP, and would only see
traffic coming from the VIP's IP.
> I appreciate the help, Chuck! Would you mind PMing me or posting your
> configs? That might be the most useful.
Pretend that some folks nearby are using Citrix Netscaler MPX boxes rather than
Cisco hardware, so this might not be too useful to your case; an example config
for a webserver would look something like:
add serviceGroup SomeService-svg HTTP -maxClient 0 -maxReq 0 -cip ENABLED
x-user-addr -usip NO -useproxyport YES -cltTimeout 120 -svrTimeout 300 -CKA YES
-TCPB YES -CMP NO
add lb vserver LB-SomeService-80 HTTP 1.2.3.4 80 -persistenceType NONE
-cltTimeout 120
bind lb vserver LB-SomeService-80 SomeService-svg
bind serviceGroup SomeService-svg rserver1 8080
bind serviceGroup SomeService-svg rserver2 8080
bind serviceGroup SomeService-svg rserver3 8080
bind serviceGroup SomeService-svg rserver4 8080
[ This is a generic example for a webserver, or for similar things which use
HTTP to communicate. Another group handles DNS, so I don't have a generic
e
Re: transparent DNS load-balancing with a Cisco ACE
Thanks Daniel. Good to hear of someone using NAT for DNS traffic. My fears of it are mostly performance-based--every DNS query takes up a new entry in the ACE's NAT table. In our case, that's thousands of queries per second that the ACE has to keep in memory. I've shown it to be a slight (25% or so) performance hit in terms of max queries/second. At this point, these are recursive-only servers, so I'm not even worried about zone transfers--that piece of the project comes next! The rservers will be doing a bunch of outbound queries, however, and using their real addresses for that. John On 10/19/2012 04:32 PM, Daniel McDonald wrote: I've not bothered with nat - just place rservers with unique addresses behind the ACE, let them use the ACE as their default gateway, and then publish a vip. The rservers use their real address for zone transfers with the master, while clients only talk with the vip address. ___ 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: transparent DNS load-balancing with a Cisco ACE
On 10/19/12 1:25 PM, "John Miller" wrote: > Hello everyone, > > Perhaps a Cisco list is a better destination for this, but I've seen a > similar post here in the past couple of months, so posting here as well. > > I'm trying to get our Cisco ACE set up appropriately to handle DNS > traffic. So far, I've gotten it working using NAT (each rserver has a > public and a private IP) and using transparent load-balancing (ACE talks > directly to the public IP), aka direct server return. I've not bothered with nat - just place rservers with unique addresses behind the ACE, let them use the ACE as their default gateway, and then publish a vip. The rservers use their real address for zone transfers with the master, while clients only talk with the vip address. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ 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: transparent DNS load-balancing with a Cisco ACE
IMO, the only boxes which should have IPs in both public and private netblocks should be your firewall/NAT routing boxes. That's how we usually have our servers set up--the load balancer gets the public IPs, the servers get the private IPs, and we use NAT to translate between the two. Here's a question, however: how does one get probes working for a transparent LB setup? If an rserver listens for connections on all interfaces, then probes work fine, but return traffic from the uses the machine's default IP (not the VIP that was originally queried) for the source address of the return traffic. That's the default routing behavior for most platforms. Some of them might support some form of policy-based routing via ipfw fwd / route-to or similar with other firewall mechanisms which would let the probes get returned from some other source address if you want them to do so. Good to know--you'd definitely expect traffic to come back on the main interface. I've considered setting up some iptables rules to make this happen, but if I can avoid it, so much the better. Sounds like this is what I need to do, however, if I want both probes and regular requests to work. What have people done to get probes working with transparent LB? Are any of you using NAT to handle your dns traffic? Not tying up NAT tables seems like the way to go, but lack of probes is a deal-breaker on this end. The locals around here have the luxury of a /8 netblock, so they can setup the reals behind a LB using publicly routable IPs and never need to NAT upon DNS traffic. Folks with more limited # of routable IPs might well use LB to reals on an unrouteable private network range behind NAT, but in which case they wouldn't configure those boxes with public IPs. We're on a /16, so we have plenty of public IPs (though not as many as you!) to play with, too. The choice to NAT has historically been more about security than anything else--if something is privately IPed, we've got it on a special VLAN as well. Presumably those reals are still behind a virtual ip address that's also public, right? If that's the case, how do you keep your probes (to the IP behind the LB) working, while still sending back regular DNS traffic (that was originally sent to the virtual IP) with the VIP as a source address? Seems like you get only one or the other unless you tweak iptables/ipfw/etc. I appreciate the help, Chuck! Would you mind PMing me or posting your configs? That might be the most useful. John - Configs: eth0 Link encap:Ethernet HWaddr DE:AD:CA:FE:BE:EF inet addr:129.64.x.11 Bcast:129.64.x.255 Mask:255.255.255.0 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING NOARP MTU:16436 Metric:1 lo:1 Link encap:Local Loopback inet addr:129.64.x.53 (VIP) Mask:255.255.255.255 UP LOOPBACK RUNNING NOARP MTU:16436 Metric:1 Here's my ACE config (IP addrs deliberately munged): access-list anyone line 10 extended permit ip any any probe dns brandeis.edu-dns description Query dns servers for brandeis.edu/A interval 5 passdetect interval 10 domain brandeis.edu expect address 129.64.99.138 rserver host dns1 description dev-level recursive DNS server; running BIND9 in the xen-ha-environment. ip address 129.64.x.11 inservice rserver host dns2 description dev-level recursive DNS server; running PowerDNS in the xen-ha-environment. ip address 129.64.x.12 inservice rserver host dns3 description dev-level recursive DNS server; running BIND9 in the XenServer environment. ip address 129.64.x.13 inservice rserver host dns4 description dev-level recursive DNS server; running PowerDNS in the XenServer environment. ip address 129.64.x.14 inservice serverfarm host dns-recursive description Dev-level recursive DNS servers--both BIND and PowerDNS transparent probe brandeis.edu-dns rserver dns1 inservice rserver dns2 inservice rserver dns3 inservice rserver dns4 inservice class-map match-all VIP 2 match virtual-address 129.64.x.53 udp eq domain policy-map type loadbalance first-match L7SLBPOLICY class class-default serverfarm dns-recursive policy-map multi-match L4SLBPOLICY class VIP loadbalance vip inservice loadbalance policy L7SLBPOLICY loadbalance vip icmp-reply active interface vlan 100 ip address 129.64.x.100 255.255.255.0 peer ip address 129.64.x.101 255.255.255.0 no normalization access-group input anyone service-policy input L4SLBPOLICY no shutdown ip route 0.0.0.0 0.0.0.0 129.64.x.1 ___ 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: transparent DNS load-balancing with a Cisco ACE
Hi-- On Oct 19, 2012, at 11:25 AM, John Miller wrote: > Hello everyone, > > Perhaps a Cisco list is a better destination for this, but I've seen a > similar post here in the past couple of months, so posting here as well. > > I'm trying to get our Cisco ACE set up appropriately to handle DNS traffic. > So far, I've gotten it working using NAT (each rserver has a public and a > private IP) and using transparent load-balancing (ACE talks directly to the > public IP), aka direct server return. IMO, the only boxes which should have IPs in both public and private netblocks should be your firewall/NAT routing boxes. > Here's a question, however: how does one get probes working for a transparent > LB setup? If an rserver listens for connections on all interfaces, then > probes work fine, but return traffic from the uses the machine's default IP > (not the VIP that was originally queried) for the source address of the > return traffic. That's the default routing behavior for most platforms. Some of them might support some form of policy-based routing via ipfw fwd / route-to or similar with other firewall mechanisms which would let the probes get returned from some other source address if you want them to do so. > What have people done to get probes working with transparent LB? Are any of > you using NAT to handle your dns traffic? Not tying up NAT tables seems like > the way to go, but lack of probes is a deal-breaker on this end. The locals around here have the luxury of a /8 netblock, so they can setup the reals behind a LB using publicly routable IPs and never need to NAT upon DNS traffic. Folks with more limited # of routable IPs might well use LB to reals on an unrouteable private network range behind NAT, but in which case they wouldn't configure those boxes with public IPs. Regards, -- -Chuck ___ 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
transparent DNS load-balancing with a Cisco ACE
Hello everyone, Perhaps a Cisco list is a better destination for this, but I've seen a similar post here in the past couple of months, so posting here as well. I'm trying to get our Cisco ACE set up appropriately to handle DNS traffic. So far, I've gotten it working using NAT (each rserver has a public and a private IP) and using transparent load-balancing (ACE talks directly to the public IP), aka direct server return. Here's a question, however: how does one get probes working for a transparent LB setup? If an rserver listens for connections on all interfaces, then probes work fine, but return traffic from the uses the machine's default IP (not the VIP that was originally queried) for the source address of the return traffic. What have people done to get probes working with transparent LB? Are any of you using NAT to handle your dns traffic? Not tying up NAT tables seems like the way to go, but lack of probes is a deal-breaker on this end. -- John Miller Systems Engineer Brandeis University johnm...@brandeis.edu ___ 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: ISC Bind in Active Directory
Nicholas F Miller wrote: >DDNS record scavenging is the only feature I'm aware of that MS DNS has >that Bind doesn't . On the flip side, ISC Bind can ACL who can add >certain record types to a dynamic zone using GSS-TSIG as well as >supports views and ACLs for recursion. Everything else should be >standard DNS. > Yeah, that would be nice to have actually. More generally, metadata on ddns records would be useful. -- Sent from my phone. Please excuse brevity and typos. ___ 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: ISC Bind in Active Directory
DDNS record scavenging is the only feature I'm aware of that MS DNS has that Bind doesn't . On the flip side, ISC Bind can ACL who can add certain record types to a dynamic zone using GSS-TSIG as well as supports views and ACLs for recursion. Everything else should be standard DNS. _ Nicholas Miller, OIT, University of Colorado at Boulder On Oct 18, 2012, at 12:03 PM, Aaron Thompson wrote: > Hi All, > > I'm hopping to get some feedback from people who use ISC Bind and DHCPD in > Active Directory environments. > > Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty > stable service, redundant and we are polling statistics with Cacti. There is > concern by Management of using a somewhat non standard approach for Active > Directory SRV records being handled by ISC services and not AD. > > The options we are looking at is migrating to AD for DNS and DHCP services or > to have Bind/DHCPD handle SRV records for AD. > > Some technical info on our our BIND environment. > > Some Client Identifiers > 300 DHCP Pools > Dynamic DNS > Cacti Graphs - Reporting > Syslog via Splunk > > Overall it's been a very stable design for the last 5+ years. > > If you have any relevant feed back I would appreciate it. I'm looking for > information on experience with Active Directory integration with ISC or if > anyone has had problems/stability issues with AD doing DNS/DHCP or AD working > with ISC. > > Thanks in advance. > > Here's a brief survey for Schools that have ISC running in an AD environment. > > http://www.surveymonkey.com/s/2VYNKWR > > - > Aaron Thompson > Network Architect for IT Operations > > Berklee College of Music > 1140 Boylston Street, MS-186-NETT > Boston, MA 02215-3693 > > www.berklee.edu > 617.747.8656 > > - > Aaron Thompson > Network Architect for IT Operations > > Berklee College of Music > 1140 Boylston Street, MS-186-NETT > Boston, MA 02215-3693 > > www.berklee.edu > 617.747.8656 > > ___ > 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: BIND 9.8.0 dns64 feature
On Fri, Oct 19, 2012 at 02:30:12PM +0530, Ashok Agarwal wrote: > I have gone thru the release note of BIND 9.8.0 to found that the > feature "* dns64*" has been implemented in this version of BIND for > the first time. I also learned that there are other features as > well besides "dns64". Now, my task is to port "dns64" in my BIND > 9.7.3 (ported for ISC BIND 9.7.3 only) but the challenge here is to > discriminate the code for "dns64" feature as I don't want to ported > the whole code difference between 9.8.0 and 9.7.7rc1. This seems a bit silly to me. Generally you should upgrade your software when you want features offered by the new version. If you don't like the other new features of 9.8.x, don't use them. They don't bite. In fact, I liked 9.8 quite well before moving to 9.9. FWIW, 9.7.7 is out of RC now, and 9.8.4 is the current release of 9.8.x. Perhaps you could take the 9.8.4 sources and patch to show a version of "9.7.7-ashok-dns64". > Therefore I request you, if you have explicit code for "dns64" > feature then please share. It's shared. You can download the full source code from isc.org. If your organization has a budget for it, you could probably hire ISC for custom programming work. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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: ISC Bind in Active Directory
On 10/18/2012 3:17 PM, bind-users-requ...@lists.isc.org wrote: Hi All, I'm hopping to get some feedback from people who use ISC Bind and DHCPD in Active Directory environments. Currently we use Bind/DHCPD for dynamic DNS and DHCP. It's been a pretty stable service, redundant and we are polling statistics with Cacti. There is concern by Management of using a somewhat non standard approach for Active Directory SRV records being handled by ISC services and not AD. The options we are looking at is migrating to AD for DNS and DHCP services or to have Bind/DHCPD handle SRV records for AD. Some technical info on our our BIND environment. Some Client Identifiers 300 DHCP Pools Dynamic DNS Cacti Graphs - Reporting Syslog via Splunk Overall it's been a very stable design for the last 5+ years. If you have any relevant feed back I would appreciate it. I'm looking for information on experience with Active Directory integration with ISC or if anyone has had problems/stability issues with AD doing DNS/DHCP or AD working with ISC. Thanks in advance. Here's a brief survey for Schools that have ISC running in an AD environment. http://www.surveymonkey.com/s/2VYNKWR - Aaron Thompson Network Architect for IT Operations Berklee College of Music 1140 Boylston Street, MS-186-NETT Boston, MA 02215-3693 www.berklee.edu 617.747.8656 - Aaron Thompson Network Architect for IT Operations What I did was to have the AD zones mastered on Windows Domain Controllers. I chose ONE of the DCs to be the "master" for slaving all of these AD zones on my BIND servers. There were NO CLIENT MACHINES (to my knowledge) tha were configured to use the Windows DNS Servers as their resolvers. All machines pointed to the BIND slaves. This let Windows AD register any SRV records it wanted; the updated zones were then transferred (via DNS protocols) to my BIND slaves. The only problem was this - when AD first appeared, the Microsoft DNS code would update the zone serial number, even if the DNS update made no change to the zone (except to update an internal timestamp in the AD-integrated zone). After I opened a support call (in the Windows Server 2000 timeframe), the MS code was changed to not increase the zone serial number if the zone contents were not really changing. As of a year ago, the code had been modified so zone serial numbers were increasing. Even with MS DHCP - if a lease was renewed, the DNS update was refused, and the DHCP server had to re-send the update with TKEY/TSIG authentication before the update was accepted. But the zone serial number was incremented, causing unnecessary zone transfers from the DC to the BIND servers. I was not allowed to open a support call with MS to see why the code was changed and to get the code changed. --Barry Finkel ___ 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
BIND 9.8.0 dns64 feature
Hello All, I have gone thru the release note of BIND 9.8.0 to found that the feature "* dns64*" has been implemented in this version of BIND for the first time. I also learned that there are other features as well besides "dns64". Now, my task is to port "dns64" in my BIND 9.7.3 (ported for ISC BIND 9.7.3 only) but the challenge here is to discriminate the code for "dns64" feature as I don't want to ported the whole code difference between 9.8.0 and 9.7.7rc1. Therefore I request you, if you have explicit code for "dns64" feature then please share. Thanks in anticipation. -- Regards, Ashok ___ 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: dhcpd
[ Not sure why this thread started on BIND-users: please continue on DHCP-users! ] On 18 Oct 2012, at 13:42, Dwayne Hottinger wrote: > I checked the mac addresses of these clients and thus far they are all ipads, > ipods or iphones. We see BOOTP transactions here at UCD (in Ireland, not California!) too. I was agreeably surprised to see that our latest monthly statistical report shows these on our copper networks only, not on wireless. IIRC, it's actually very easy for the user to configure any of the iDevices to use DHCP instead of BOOTP. Jim Glassford's suggestion seems good enough to me. On 18 Oct 2012, at 14:28, Jim Glassford wrote: > We just continue to deny bootp for subnets that have no need for it and > ignore them. Best regards, Niall O'Reilly University College Dublin IT Services ___ 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
