Re: BIND with DLZ doesn't reconnect to the MySQL 5.x server after disconnect
In message 4ab9c360.7090...@dougbarton.us, Doug Barton writes: I recently added DLZ options to the BIND ports on FreeBSD, and a user has filed the following problem report: http://www.freebsd.org/cgi/query-pr.cgi?pr=139051 Does anyone have any comment on the patch suggested at the URL in the PR? http://www.shell-tips.com/2007/09/04/bind-950-patch-dlz-mysql-5-for-auto-recon nect/ Is this something that is likely to be included in a BIND distribution any time soon? Reconnect is already being set. B.T.W. the patch passes a pointer to the wrong type to mysql_options() see http://dev.mysql.com/doc/refman/5.1/en/mysql-options.html Thanks, Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
rndc command for erased zone?
I no longer manage one of our DNS domain. As I use 'rndc reconfig' to load newly created zones I was wondering if exists a way to do the same as reconfig but inversely, I mean, reload configuration forgetting the just erased zones. I tried every command that rndc has, but I guess that my only choice is to restart bind. I even tried flushing cache, but it keeps answering to DNS queries to that zone even when I erased the zone file. Is there a way to do this without stopping and starting the named daemon? Thanks in advance and thanks everyone that helped me out in my last thread. -- ,---. | The United States is like the guy at the party who gives cocaine | | to everybody and still nobody likes him. | | -- Jim Samuels| |---| | Técnico de Sistemas| | | Departamento de Informática| Debian GNU/Linux Powerer | | Ayuntamiento de Getafe |.--. | || |o_o | | | _ | .''`.|:_/ | | | |~~ @| Marcos Lorenzo de Santiago | : :' : // \ \| | | | marcos.lore...@ayto-getafe.org | `. `' (| | ) | | |_| Teléfono: (+34) 91-202-79-48 | `- /'\_ _/`\ | | Móvil:(+34) 608-300-935 |\___)=(___/ | || | `---' ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc command for erased zone?
On 23.09.09 14:00, Marcos Lorenzo de Santiago wrote: I no longer manage one of our DNS domain. As I use 'rndc reconfig' to load newly created zones I was wondering if exists a way to do the same as reconfig but inversely, I mean, reload configuration forgetting the just erased zones. I tried every command that rndc has, but I guess that my only choice is to restart bind. I even tried flushing cache, but it keeps answering to DNS queries to that zone even when I erased the zone file. does it return authoritative responses? Does the server allow recursion for you? I think rndc reconfig should forget removed zones too, but you may be - either seeing the same zone in other view - see records fetched from other servers after zone was removed -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. LSD will make your ECS screen display 16.7 million colors ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc command for erased zone?
In article mailman.574.1253708535.14796.bind-us...@lists.isc.org, Matus UHLAR - fantomas uh...@fantomas.sk wrote: On 23.09.09 14:00, Marcos Lorenzo de Santiago wrote: I no longer manage one of our DNS domain. As I use 'rndc reconfig' to load newly created zones I was wondering if exists a way to do the same as reconfig but inversely, I mean, reload configuration forgetting the just erased zones. I tried every command that rndc has, but I guess that my only choice is to restart bind. I even tried flushing cache, but it keeps answering to DNS queries to that zone even when I erased the zone file. does it return authoritative responses? Does the server allow recursion for you? I think rndc reconfig should forget removed zones too, but you may be - either seeing the same zone in other view - see records fetched from other servers after zone was removed rndc reconfig does remove zones. If logging is set appropriately you should see messages something like this: 02-Sep-2009 10:02:30.995 general: zone 193.215.129.in-addr.arpa/IN/default: (slave) removed That won't remove any files from either master or slave servers, but should stop your server from answering authoritatively. If there are other servers and you haven't deleted the delegation then there will still be traces of the domain around. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND with DLZ doesn't reconnect to the MySQL 5.x server after disconnect
Mark Andrews wrote: In message 4ab9c360.7090...@dougbarton.us, Doug Barton writes: I recently added DLZ options to the BIND ports on FreeBSD, and a user has filed the following problem report: http://www.freebsd.org/cgi/query-pr.cgi?pr=139051 Does anyone have any comment on the patch suggested at the URL in the PR? http://www.shell-tips.com/2007/09/04/bind-950-patch-dlz-mysql-5-for-auto-recon nect/ Is this something that is likely to be included in a BIND distribution any time soon? Reconnect is already being set. B.T.W. the patch passes a pointer to the wrong type to mysql_options() see http://dev.mysql.com/doc/refman/5.1/en/mysql-options.html Thanks Mark. I've asked the user to follow up on this list so that hopefully we can reach a conclusion on the right solution. Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc command for erased zone?
On Wed, Sep 23, 2009 at 8:00 AM, Marcos Lorenzo de Santiago marcos.lore...@ayto-getafe.org wrote: I no longer manage one of our DNS domain. As I use 'rndc reconfig' to load newly created zones I was wondering if exists a way to do the same as reconfig but inversely, I mean, reload configuration forgetting the just erased zones. I tried every command that rndc has, but I guess that my only choice is to restart bind. I even tried flushing cache, but it keeps answering to DNS queries to that zone even when I erased the zone file. Maybe you are deleting the zone data, but not removing the entry from the BIND config file? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Dig ANY gives SERVFAIL / FORMERR
Hi, I operate a caching naming server version 9.5.0-P1 for a small work group that includes an email server. From the server log file, there are occasional DNS error messages. Upon closer examination using a packet sniffer, the email server sends out queries of type ANY for all sender/recipient domain names. There are just some domains which cause errors, for example, youbei.cc (which is not under our control.) I tried dig any youbei.cc and it returns the following error: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 64259 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 With heavy tracing turned on and rndc flush before executing the command, it gave the following log entries that I excerpted below: 24-Sep-2009 02:07:35.878 received packet: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 28529 ;; flags: qr aa ; QUESTION: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3 ;; QUESTION SECTION: ;youbei.cc. IN A ;; ANSWER SECTION: youbei.cc. 86400 IN SOA ns1.72dns.com. admin.youbei.cc. 100 3600 900 86400 3600 youbei.cc. 3600IN NS ns1.72dns.com. youbei.cc. 3600IN NS ns2.72dns.com. youbei.cc. 3600IN MX 10 mail.youbei.cc. youbei.cc. 3600IN A 211.155.230.241 ;; ADDITIONAL SECTION: ns1.72dns.com. 3600IN A 121.12.173.174 ns2.72dns.com. 3600IN A 211.155.230.241 mail.youbei.cc. 3600IN A 58.61.157.116 24-Sep-2009 02:07:35.879 fctx d18160(youbei.cc/ANY'): cancelquery 24-Sep-2009 02:07:35.879 sockmgr dbea0: watcher got message -2 for socket -1 24-Sep-2009 02:07:35.880 dispatch 160dc88 response 160ce28 121.12.173.174#53: detaching from task ca310 24-Sep-2009 02:07:35.880 dispatch 160dc88: detach: refcount 0 24-Sep-2009 02:07:35.880 fctx d18160(youbei.cc/ANY'): add_bad 24-Sep-2009 02:07:35.881 dispatch 160dc88: got packet: requests 0, buffers 1, recvs 1 24-Sep-2009 02:07:35.881 FORMERR resolving 'youbei.cc/ANY/IN': 121.12.173.174#53 24-Sep-2009 02:07:35.881 fctx d18160(youbei.cc/ANY'): try 24-Sep-2009 02:07:35.882 fctx d18160(youbei.cc/ANY'): query It looks like that the authoritative name server for youbei.cc actually did return some answers, but somehow bind gave a FORMERR for some unknown reasons, which I think it caused a SERVFAIL to be reported in turn. Interestingly, dig any youbei.cc +trace ran successfully and did not report any error. Does anyone know what might have caused this problem? Best regards, Patrick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dig ANY gives SERVFAIL / FORMERR
It looks like that the authoritative name server for youbei.cc actually did return some answers, but somehow bind gave a FORMERR for some unknown reasons, which I think it caused a SERVFAIL to be reported in turn. Interestingly, dig any youbei.cc +trace ran successfully and did not report any error. Does anyone know what might have caused this problem? My custom named logs: 23-Sep-2009 15:00:29.749 resolver: notice: FORMERR: Type didn't match (ANY != A) 23-Sep-2009 15:00:29.770 resolver: notice: FORMERR: Reply has no answer. named wants to know Is the question the same as the one we asked? I think 72dns.com has a broken DNS server. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dig ANY gives SERVFAIL / FORMERR
In message alpine.neb.2.01.0909231442321@t1.m.reedmedia.net, Jeremy C. Re ed writes: It looks like that the authoritative name server for youbei.cc actually did return some answers, but somehow bind gave a FORMERR for some unknown reasons, which I think it caused a SERVFAIL to be reported in turn. Interestingly, dig any youbei.cc +trace ran successfully and did not report any error. Does anyone know what might have caused this problem? My custom named logs: 23-Sep-2009 15:00:29.749 resolver: notice: FORMERR: Type didn't match (ANY != A) 23-Sep-2009 15:00:29.770 resolver: notice: FORMERR: Reply has no answer. named wants to know Is the question the same as the one we asked? I think 72dns.com has a broken DNS server. More modern versions of dig will also report the mismatch. The servers also answers queries with A records. It's a pity registries are not required to verify correct operation of the nameservers they are delegating to before accepting the delegation. If they were then a lot of this garbage would cease. It really isn't hard for a registry (or the registrar on behalf of the registry) to check that servers answer queries correctly. Just the almighty dollar has got in front of having a working system. Mark % dig any youbei.cc @ns1.72dns.com ;; Question section mismatch: got youbei.cc/A/IN ;; Question section mismatch: got youbei.cc/A/IN ;; Question section mismatch: got youbei.cc/A/IN ; DiG 9.7.0a2 any youbei.cc @ns1.72dns.com ;; global options: +cmd ;; connection timed out; no servers could be reached % % dig youbei.cc @ns1.72dns.com ; DiG 9.3.6-P1 youbei.cc @ns1.72dns.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 5189 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;youbei.cc. IN ;; ANSWER SECTION: youbei.cc. 3600IN A 211.155.230.241 ;; Query time: 436 msec ;; SERVER: 121.12.173.174#53(121.12.173.174) ;; WHEN: Thu Sep 24 07:07:46 2009 ;; MSG SIZE rcvd: 52 % ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.5.2 is now available.
--- Blind-Carbon-Copy To: bind-annou...@isc.org From: Mark Andrews ma...@isc.org Subject: BIND 9.5.2 is now available. Date: Thu, 24 Sep 2009 11:01:29 +1000 Sender: ma...@drugs.dv.isc.org BIND 9.5.2 is now available. BIND 9.5.2 is a maintenance release for BIND 9.5. BIND 9.5.2 can be downloaded from ftp://ftp.isc.org/isc/bind9/9.5.2/bind-9.5.2.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.5.2/bind-9.5.2.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.5.2/bind-9.5.2.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.5.2/bind-9.5.2.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at https://www.isc.org/about/openpgp. A binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.zip ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.debug.zip The PGP signature of the binary kit for Windows XP and Window 2003 is at ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.zip.asc ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.5.2/BIND9.5.2.debug.zip.sha512.asc Changes since 9.5.0. --- 9.5.2 released --- 2681. [bug] IPSECKEY RR of gateway type 3 was not correctly decoded. [RT #20269] 2678. [func] Treat DS queries as if minimal-response yes; was set. [RT #20258] 2427. [func] Treat DNSKEY queries as if minimal-response yes; was set. [RT #18528] --- 9.5.2rc1 released --- 2672. [bug] Don't enable searching in 'host' when doing reverse lookups. [RT #20218] 2670. [bug] Unexpected connect failures failed to log enough information to be useful. [RT #20205] 2663. [func] win32: allow named to run as a service using NT AUTHORITY\LocalService as the account. [RT #19977] 2656. [func] win32: add a tools only check box to the installer which causes it to only install dig, host, nslookup, nsupdate and relevent dlls. [RT #19998] 2655. [doc] Document that key-directory does not affect rndc.key. [RT #20155] --- 9.5.2b1 released --- 2649. [bug] Set the domain for forward only zones. [RT #19944] 2648. [port] win32: isc_time_seconds() was broken. [RT #19900] 2646. [bug] Incorrect cleanup on error in socket.c. [RT #19987] 2645. [port] gcc -m32 didn't work on amd64 and x86_64 platforms which default to 64 bits. [RT #19927] 2642. [bug] nsupdate could dump core on solaris when reading improperly formatted key files. [RT #20015] 2640. [security] A specially crafted update packet will cause named to exit. [RT #2] 2637. [func] Rationalize dnssec-signzone's signwithkey() calling. [RT #19959] 2635. [bug] isc_inet_ntop() incorrectly handled 0.0/16 addresses. [RT #19716] 2633. [bug] Handle 15 bit rand() functions. [RT #19783] 2632. [func] util/kit.sh: warn if documentation appears to be out of date. [RT #19922] 2623. [bug] Named started seaches for DS non-optimally. [RT #19915] 2621. [doc] Made copyright boilterplate consistent. [RT #19833] 2920. [bug] Delay thawing the zone until the reload of it has completed successfully. [RT #19750] 2618. [bug] The sdb and sdlz db_interator_seek() methods could loop infinitely. [RT #19847] 2617. [bug] ifconfig.sh failed to emit an error message when run from the wrong location. [RT #19375] 2616. [bug] 'host' used the nameservers from resolv.conf even when a explicit nameserver was specified. [RT #19852] 2615. [bug] __attribute__((unused)) was in the wrong place for ia64 gcc builds. [RT #19854] 2614. [port] win32: 'named -v' should automatically be executed in the foreground. [RT #19844] 2610. [port] sunos: Change #2363 was not complete. [RT #19796] 2606. [bug] delegation-only was not being accepted in delegation-only type zones. [RT #19717] 2605. [bug] Accept DS responses from delegation only zones. [RT # 19296] 2603. [port]
Re: Need help on delegation to subdomain/external servers
The re-design of the DNS network architecture was one of the few
internal projects where a credible Concept of Operations document
was produced. It had detailed graphics showing the flow of network
traffic between local and regional name servers. There were detailed
discussions and graphics explaining how local name servers would fail
over to another regional name server and which regional name server
would be used under certain failure conditions.
The unfortunate aspect is, simply, that IT colleagues (and
management) believe that the document is right.
On 21 Sep 2009, at 14:31:39, Kevin Darcy wrote:
What is unfortunate about BIND picking a forwarder based on real,
up-to-date information about the thing that the end-user ultimately
cares about -- how quickly the queries get answered?
Surely this is better than hardcoding a bunch of assumptions into
your forwarding configs, assumptions that can be trivially
invalidated by such factors as nameserver failures, nameserver
performance bottlenecks, network congestion, route flapping and
other topographical anomalies, query usage patterns, etc.
If you want more fine-grained control of your query traffic, for
reasons other than pure query performance (e.g. you might pay per-
byte on link A but a flat rate on link B), then you might have to
resort to devices and/or mechanisms outside of named in order to
accomplish it, e.g. traffic shapers, transparent DNS proxies and the
like.
- Kevin
Merton Campbell Crockett wrote:
When I was transferred into our corporate IT Networks group, I
inherited a DNS architecture based on forwarding DNS queries to
regional name servers. The regional name servers had access to the
Internet and were able to provide name and address resolution for
both Intranet and Internet queries.
The designers of the DNS architecture carefully configured the
forwarders statement on each name server so that the name server
for the region was listed first. It was followed by the other
regional name servers ordered by distance from the local name server.
Had this been implemented under BIND 8, it would have worked as the
designers had expected. Unfortunately, it was implemented under
BIND 9.3. The list of name servers in the forwarders statement was
no longer treated as a sequential list as it had been in BIND 8.
Under BIND 9.3 and later releases, the selection of name server
from the forwarders list is performed the same way as the selection
of name server for a DNS zone: its round-robin with a preference
given to the name server with the smallest RTT.
Another item that the designers didn't anticipate was how RTT is
calculated. It is not based on the RTT to the forwarder but on the
time that it takes for the forwarder to return a result. Given the
physical locations of the regional name servers, the calculated RTT
is roughly identical even at sites where there is a local name
server co-located with the regional name server. In our particular
environment, the primary forwarder changes approximately every
20-30 seconds.
Given this behavior, I'm not sure what advantage there is in having
online and offline name servers. I would opt for having all
name servers online and let BIND select the more desirable name
server.
On 17 Sep 2009, at 11:15:59, Ben Croswell wrote:
I have done some testing of the RTT forwarding and found that as
long as only one, or the other of the two nameservers that you
forward to is active at any given time the switch over is actually
very quick.
The exception being the first query when the currently active
forwarder dies and the second comes up. The reason being that the
first query has to wait for a timeout cycle before trying the
second forwarder and readjusting the RTT values for both.
So theoretically if your forwarders are 10.1.1.1 and 10.2.1.1 as
long as only one will answer queries at a given time with their
own right answer it should failover fairly quickly. If both
answer then you will be at the mercy of the RTT as to which answer
you will get.
--
-Ben Croswell
On Thu, Sep 17, 2009 at 12:27 PM, Kevin Darcy k...@chrysler.com mailto:k...@chrysler.com
wrote:
RUOFF LARS wrote:
[mailto:bind-users-boun...@lists.isc.org
mailto:bind-users-boun...@lists.isc.org] On Behalf Of
Kevin Darcy
BTW, at the moment I am experimenting a solution usign a
forward zone:
zone dummy.ts IN {
type forward;
forward only;
forwarders { 172.25.32.171; 192.168.2.3; };
};
It seems to work.
I guess that the requests are not sent simultaneously though?
Correct, it's similar to the algorithm that a stub resolver uses:
try one forwarder, if it times
