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
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: 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
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
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: ISC Bind in Active Directory
Nicholas F Miller nicholas.mil...@colorado.edu 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
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: 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
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
On 10/19/12 1:25 PM, John Miller johnm...@brandeis.edu 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
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 example for that handy. And yeah, NDA issues prevent me from being as
Re: ISC Bind in Active Directory
On Oct 19, 2012, at 13.27, Phil Mayers wrote: Nicholas F Miller nicholas.mil...@colorado.edu 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: Disable log message
On Oct 18, 2012, at 1:13 PM, Chris Thompson c...@cam.ac.uk 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: 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 bind-us...@isc.org Subject: Re: Disable log message On Oct 18, 2012, at 1:13 PM, Chris Thompson c...@cam.ac.uk 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: transparent DNS load-balancing with a Cisco ACE
-Original Message- From: Chuck Swiger cswi...@mac.com Date: Friday, October 19, 2012 5:09 PM To: John Miller johnm...@brandeis.edu Cc: DNS BIND bind-us...@isc.org 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
On Oct 19, 2012, at 6:13 PM, Alan Clegg a...@clegg.com wrote: On Oct 18, 2012, at 1:13 PM, Chris Thompson c...@cam.ac.uk 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: Disable log message
-Original Message- From: Warren Kumari war...@kumari.net Date: Friday, October 19, 2012 8:56 PM To: Alan Clegg a...@clegg.com Cc: bind-us...@isc.org bind-us...@isc.org Subject: Re: Disable log message On Oct 19, 2012, at 6:13 PM, Alan Clegg a...@clegg.com wrote: On Oct 18, 2012, at 1:13 PM, Chris Thompson c...@cam.ac.uk 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 9:17 PM, Michael Hoskins (michoski) micho...@cisco.com wrote: -Original Message- From: Warren Kumari war...@kumari.net Date: Friday, October 19, 2012 8:56 PM To: Alan Clegg a...@clegg.com Cc: bind-us...@isc.org bind-us...@isc.org Subject: Re: Disable log message On Oct 19, 2012, at 6:13 PM, Alan Clegg a...@clegg.com wrote: On Oct 18, 2012, at 1:13 PM, Chris Thompson c...@cam.ac.uk 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
On Oct 19, 2012, at 6:22 PM, Warren Kumari wrote: On Oct 19, 2012, at 9:17 PM, Michael Hoskins (michoski) micho...@cisco.com wrote: -Original Message- On Oct 19, 2012, at 6:13 PM, Alan Clegg a...@clegg.com wrote: On Oct 18, 2012, at 1:13 PM, Chris Thompson c...@cam.ac.uk 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
