Re: Core dumping DLZ
On Thu, May 07, 2009 at 09:20:28PM -0700, Scott Haneda wrote: > On May 7, 2009, at 6:51 PM, Mark Andrews wrote: > >>> (gdb) backtrace >>> #0 0x2adb2b0e0215 in raise () from /lib64/libc.so.6 >>> #1 0x2adb2b0e1cc0 in abort () from /lib64/libc.so.6 >>> #2 0x2adb27c4c9e0 in assertion_failed (file=0x2adb2922428b >>> "mem.c", line=918, type=, cond=0x2adb292245b5 >>> "ctx->stats[i].gets == 0U") >>> at ./main.c:166 >>> #3 0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918 >>> #4 0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at >>> mem.c:1067 >>> #5 0x2adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./ >>> main.c:1064 >> >> This is indicative of a memory / reference leak being >> detected on shutdown. > > > I just had two more happen. This is not even a production server as of > yet, it is being readied for that though. There should be very little > hitting named-sdb at this point... > > (gdb) backtrace > #0 0x2af5a089fdfb in ?? () from /usr/lib64/mysql/ > libmysqlclient.so.15 > #1 0x2af5a08a0179 in my_net_read () from /usr/lib64/mysql/ > libmysqlclient.so.15 > #2 0x2af5a0899922 in cli_safe_read () from /usr/lib64/mysql/ > libmysqlclient.so.15 > #3 0x2af5a089a9f9 in ?? () from /usr/lib64/mysql/ > libmysqlclient.so.15 > #4 0x2af5a0898f9e in mysql_real_query () >from /usr/lib64/mysql/libmysqlclient.so.15 > #5 0x2af59f09c67a in mysql_get_resultset (zone=0x4542f960 > "ns1.*.com", > record=, client=0x0, query=4, > dbdata=0x2af59f3391e0, > rs=0x4542f918) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:324 > #6 0x2af59f09c80b in mysql_findzone (driverarg= out>, > dbdata=0x2af59f3391e0, name=0x4542f960 "ns1.**.com") > at ../../contrib/dlz/drivers/dlz_mysql_driver.c:515 > #7 0x2af59f7c8353 in dns_sdlzfindzone (driverarg=0x2af59f2fc410, > dbdata=0x2af59f3391e0, mctx=0x2af59f2ea6c0, rdclass=1, > name=0x4542fdf0, > dbp=0x45430058) at sdlz.c:1461 > #8 0x2af59f72cf22 in dns_dlzfindzone (view=0x2af59f3d8d20, > name=0x2afda090, > minlabels=3, dbp=0x45430058) at dlz.c:294 > #9 0x2af59f06add4 in query_getdb (client=0x2afd1b20, > name=0x2afda090, > qtype=, options=0, zonep=0x45431050, > dbp=0x454310b8, > versionp=0x45431058, is_zonep=0x454310cc) at query.c:925 > #10 0x2af59f06fe92 in query_find (client=0x2afd1b20, event=0x0, > qtype=1) > at query.c:3805 > #11 0x2af59f0735cd in ns_query_start (client=0x2afd1b20) at > query.c:5095 > #12 0x2af59f06026d in client_request (task=, > event=) at client.c:1898 > #13 0x2af5a0629e2c in run (uap=) at task.c:862 > #14 0x2af5a1ae2367 in start_thread () from /lib64/libpthread.so.0 > #15 0x2af5a259f0ad in clone () from /lib64/libc.so.6 > > This looks MySql related. I have mysql query logging enabled, so I can > see what comes in. So far, nothing looks malformed, which is a sure fire > way to make one of these core dumps happen. Please open a ticket in Red Hat issue tracker (preferred method) or in Red Hat bugzilla about this issue. It is a bug somewhere in code. Regards, Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
no NS but having A record
Hello, For this domain, gdpu.cn, I tried to find its ns record: dig gdpu.cn ns with no results. But I can dig its www record as below. why this happened? I can't understand entirely.. Thanks. # dig www.gdpu.cn ; <<>> DiG 9.5.0-P2 <<>> www.gdpu.cn ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59573 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.gdpu.cn. IN A ;; ANSWER SECTION: www.gdpu.cn.2742IN A 219.136.229.45 ;; AUTHORITY SECTION: gdpu.cn.13652 IN NS dns2.gdpu.cn. gdpu.cn.13652 IN NS dns1.gdpu.cn. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no NS but having A record
Is it still happening? Can you show dig output for "dig gdpu.cn ns" On May 11, 2009, at 2:56 AM, Tech W. wrote: Hello, For this domain, gdpu.cn, I tried to find its ns record: dig gdpu.cn ns with no results. But I can dig its www record as below. why this happened? I can't understand entirely.. Thanks. # dig www.gdpu.cn ; <<>> DiG 9.5.0-P2 <<>> www.gdpu.cn ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59573 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.gdpu.cn. IN A ;; ANSWER SECTION: www.gdpu.cn.2742IN A 219.136.229.45 ;; AUTHORITY SECTION: gdpu.cn.13652 IN NS dns2.gdpu.cn. gdpu.cn.13652 IN NS dns1.gdpu.cn. -- Scott * If you contact me off list replace talklists@ with scott@ * ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no NS but having A record
On May 11, 2009, at 2:56 AM, Tech W. wrote: For this domain, gdpu.cn, I tried to find its ns record: dig gdpu.cn ns with no results. But I can dig its www record as below. why this happened? I can't understand entirely.. Thanks. Actually, here is what I get back: $dig gdpu.cn ns ; <<>> DiG 9.4.2-P2 <<>> gdpu.cn ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36064 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; ANSWER SECTION: gdpu.cn.3548IN NS gdpu.cn. gdpu.cn.3548IN NS dns4.dmz.local. ;; Query time: 16 msec ;; SERVER: 208.67.222.222#53(208.67.222.222) ;; WHEN: Mon May 11 03:44:13 2009 ;; MSG SIZE rcvd: 67 I do not think you can have a .local NS. Both of those NS's have to be reachable by the outside world, and .local is not. It may be on your local lan, but outside that, it will not be. -- Scott * If you contact me off list replace talklists@ with scott@ * ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no NS but having A record
Hi, Firstly the DNS serveres for that domain is not mastered by me. I got the NS dig info as below. You can see, if I specify another public DNS (211.66.80.161), the results can be fetched. If I don't specify a DNS (use the default one 202.96.128.143 of my ISP), dig gets nothing. So I'm really confused on their configure. Please help again, thanks~ # dig gdpu.cn ns @211.66.80.161 ; <<>> DiG 9.5.0-P2 <<>> gdpu.cn ns @211.66.80.161 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57139 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; ANSWER SECTION: gdpu.cn.21347 IN NS dns2.gdpu.cn. gdpu.cn.21347 IN NS dns1.gdpu.cn. ;; ADDITIONAL SECTION: dns2.gdpu.cn. 21347 IN A 219.136.229.42 dns1.gdpu.cn. 21347 IN A 219.136.229.41 ;; Query time: 3 msec ;; SERVER: 211.66.80.161#53(211.66.80.161) ;; WHEN: Mon May 11 18:51:19 2009 ;; MSG SIZE rcvd: 95 # dig gdpu.cn ns ; <<>> DiG 9.5.0-P2 <<>> gdpu.cn ns ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15877 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; Query time: 1 msec ;; SERVER: 202.96.128.143#53(202.96.128.143) ;; WHEN: Mon May 11 18:51:24 2009 ;; MSG SIZE rcvd: 25 --- On Mon, 11/5/09, Scott Haneda wrote: > > I do not think you can have a .local NS. Both of > those NS's have to be reachable by the outside world, and > .local is not. It may be on your local lan, but outside > that, it will not be. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no NS but having A record
The zone appears to be configured incorrectly. That is why your results and Scott's are so odd. I'll explain below, but in summary, the name servers to which the zone is delegated have what appears to be rubbish records. Specifically these: gdpu.cn.3600IN NS gdpu.cn. gdpu.cn.3600IN NS dns4.dmz.local. ;; ADDITIONAL SECTION: gdpu.cn.3600IN A 219.136.229.43 dns4.dmz.local. 3600IN A 10.55.11.11 I'll explain in a little more detail... First check the delegation: (I've reduced the output for the sake of readability) arapahoe:~ kfeher$ dig ns cn +short a.dns.cn. ns.cernet.net. b.dns.cn. d.dns.cn. c.dns.cn. e.dns.cn. Then query one of those servers for the domains NS record: arapahoe:~ kfeher$ dig ns gdpu.cn @D.DNS.cn ;; AUTHORITY SECTION: gdpu.cn.21600 IN NS dns1.gdpu.cn. gdpu.cn.21600 IN NS dns2.gdpu.cn. ;; ADDITIONAL SECTION: dns1.gdpu.cn. 21600 IN A 219.136.229.41 dns2.gdpu.cn. 21600 IN A 219.136.229.42 This is correct so far. Lets see if the 2 name servers agree... arapahoe:~ kfeher$ dig ns gdpu.cn @dns2.gdpu.cn ;; QUESTION SECTION: ;gdpu.cn. IN NS ;; ANSWER SECTION: gdpu.cn.3600IN NS gdpu.cn. gdpu.cn.3600IN NS dns4.dmz.local. ;; ADDITIONAL SECTION: gdpu.cn.3600IN A 219.136.229.43 dns4.dmz.local. 3600IN A 10.55.11.11 A 10.x.x.x address is an rfc1918 address and is either internal zone information leaking to the outside world, or just plan wrong. In any case you will not be able to query it. The other address does not respond to DNS queries. I suspect this is in fact a webserver accidentally listed as a nameserver. Note that the reason your queries fail is because name servers are supposed to assume that the apex of the zone contains the most correct data. Therefore if the 2 name servers to which this zone is delegated respond with rubbish, your resolver will cache that rubbish. If you know the owner of that domain their name server should have these 2 records most likely: gdpu.cn.21600 IN NS dns1.gdpu.cn. gdpu.cn.21600 IN NS dns2.gdpu.cn. On 11/5/09 12:57 PM, "Tech W." wrote: > > Hi, > > Firstly the DNS serveres for that domain is not mastered by me. > I got the NS dig info as below. > You can see, if I specify another public DNS (211.66.80.161), the results can > be fetched. If I don't specify a DNS (use the default one 202.96.128.143 of my > ISP), dig gets nothing. > So I'm really confused on their configure. > Please help again, thanks~ > > > # dig gdpu.cn ns @211.66.80.161 > > ; <<>> DiG 9.5.0-P2 <<>> gdpu.cn ns @211.66.80.161 > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57139 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;gdpu.cn. IN NS > > ;; ANSWER SECTION: > gdpu.cn.21347 IN NS dns2.gdpu.cn. > gdpu.cn.21347 IN NS dns1.gdpu.cn. > > ;; ADDITIONAL SECTION: > dns2.gdpu.cn. 21347 IN A 219.136.229.42 > dns1.gdpu.cn. 21347 IN A 219.136.229.41 > > ;; Query time: 3 msec > ;; SERVER: 211.66.80.161#53(211.66.80.161) > ;; WHEN: Mon May 11 18:51:19 2009 > ;; MSG SIZE rcvd: 95 > > > # dig gdpu.cn ns > > ; <<>> DiG 9.5.0-P2 <<>> gdpu.cn ns > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15877 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;gdpu.cn. IN NS > > ;; Query time: 1 msec > ;; SERVER: 202.96.128.143#53(202.96.128.143) > ;; WHEN: Mon May 11 18:51:24 2009 > ;; MSG SIZE rcvd: 25 > > --- On Mon, 11/5/09, Scott Haneda wrote: > >> >> I do not think you can have a .local NS. Both of >> those NS's have to be reachable by the outside world, and >> .local is not. It may be on your local lan, but outside >> that, it will not be. > > > > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no NS but having A record
Thanks Kal. That let things be clear. --- On Mon, 11/5/09, Kal Feher wrote: > > Note that the reason your queries fail is because name > servers are supposed > to assume that the apex of the zone contains the most > correct data. > Therefore if the 2 name servers to which this zone is > delegated respond with > rubbish, your resolver will cache that rubbish. > > If you know the owner of that domain their name server > should have these 2 > records most likely: > > gdpu.cn. > 21600 IN > NS dns1.gdpu.cn. > gdpu.cn. > 21600 IN > NS dns2.gdpu.cn. > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
looking for reference to correct behavior
My apologies if this is considered to be too off-topic. I have a situation where my company uses a number of servers with a commercial DNS implementation (in addition to our BIND servers). The other implementation is Windows DNS, and there is some behavior that I do not think is acceptable, but which the vendor claims is acceptable behavior. I really want them to fix this bug (as I consider it), but first I need to get general agreement that it is a bug. I will be looking through the RFCs as much as I can time for, but haven't found what I need yet. Since my next meeting with the vendor is tomorrow, I thought I would also ask if anyone can already point me to a relevant RFC or other reference. Here is the behavior that I think is not acceptable. We have configured a zone on the windows server - dmz.example.com. This zone contains an A record for foo.dmz.example.com with IP address 10.240.240.240. The zone example.com is hosted elsewhere and contains a CNAME record foo.example.com pointing to foo.dmz.example.com. If the cache has just been cleared, and a client asks the WIndows DNS server for foo.example.com, it has a forwarding server to which it forwards the request. The forwarding server hands it back the CNAME record but it also hands back an A record for foo.dmz.example.com pointing to an incorrect IP address 192.168.240.240. The Windows DNS server accepts this A record for foo.dmz.example.com with an incorrect IP address into its cache, and hands out that incorrect information to the client. Even though it concurrently has dmz.gannett.com configured on it as a primary zone with a record for that same owner name pointing to a different IP address. I believe it shouldn't do that. Since it hosts dmz.example.com as a primary zone, I think it should discard that bad A record and hand back its own. The vendor's argument is that it should blindly trust the forwarding resolver. Can anyone point me to an RFC or reference about this? Thanks, Maria ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: looking for reference to correct behavior
The "resolver algorithm" in RFC 1034, Section 5.3.3, states 1. See if the answer is in local information, and if so return it to the client. and is further detailed as Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be good enough for normal use. Some resolvers have an option at the user interface which will force the resolver to ignore the cached data and consult with an authoritative server. This is not recommended as the default. If the resolver has direct access to a name server's zones, it should check to see if the desired data is present in authoritative form, and if so, use the authoritative data in preference to cached data. This would be a case where the resolver "has direct access to the name server's zones", so there is no debate, in my opinion, that the resolver in question is doing The Wrong Thing. RFC 2181 also makes it clear that authoritative data ranks higher than cached data, so that could also be used as a relevant normative reference. - Kevin Maria Iano wrote: My apologies if this is considered to be too off-topic. I have a situation where my company uses a number of servers with a commercial DNS implementation (in addition to our BIND servers). The other implementation is Windows DNS, and there is some behavior that I do not think is acceptable, but which the vendor claims is acceptable behavior. I really want them to fix this bug (as I consider it), but first I need to get general agreement that it is a bug. I will be looking through the RFCs as much as I can time for, but haven't found what I need yet. Since my next meeting with the vendor is tomorrow, I thought I would also ask if anyone can already point me to a relevant RFC or other reference. Here is the behavior that I think is not acceptable. We have configured a zone on the windows server - dmz.example.com. This zone contains an A record for foo.dmz.example.com with IP address 10.240.240.240. The zone example.com is hosted elsewhere and contains a CNAME record foo.example.com pointing to foo.dmz.example.com. If the cache has just been cleared, and a client asks the WIndows DNS server for foo.example.com, it has a forwarding server to which it forwards the request. The forwarding server hands it back the CNAME record but it also hands back an A record for foo.dmz.example.com pointing to an incorrect IP address 192.168.240.240. The Windows DNS server accepts this A record for foo.dmz.example.com with an incorrect IP address into its cache, and hands out that incorrect information to the client. Even though it concurrently has dmz.gannett.com configured on it as a primary zone with a record for that same owner name pointing to a different IP address. I believe it shouldn't do that. Since it hosts dmz.example.com as a primary zone, I think it should discard that bad A record and hand back its own. The vendor's argument is that it should blindly trust the forwarding resolver. Can anyone point me to an RFC or reference about this? Thanks, Maria ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Several basic questions (and yes, I've looked at the documentation on the web)
What there is of it. It seems VERY outdated since, if I understand
correctly, DLZ is now built into bind 9.5/9.6.
I have downloaded and installed the following RPMs to my DNS server,
which is a VM running RHEL 5.2:
bind-9.5.1-2.P2.el5.pp.x86_64.rpm
bind-libs-9.5.1-2.P2.el5.pp.x86_64.rpm
bind-sdb-9.5.1-2.P2.el5.pp.x86_64.rpm
bind-utils-9.5.1-2.P2.el5.pp.x86_64.rpm
I have added the exact DLZ configuration from the DLZ web page, other
than the IP address and userid for the DB.
dlz "postgres zone" {
database "postgres 1
{host=int-dbs port=5432 dbname=dns_data user=postgres}
{select zone from dns_records where zone = '%zone%'}
{select ttl, type, mx_priority, case when lower(type)='txt' then '\"'
|| data || '\"' when lower(type)='soa' then data || ' ' ||
resp_person || ' '
|| serial || ' ' || refresh || ' ' || retry || ' ' || expire ||
' ' || minimum
else data end from dns_records where zone = '%zone%' and host =
'%record%'}
{}
{select ttl, type, host, mx_priority, case when lower(type)='txt'
then '\"'
|| data || '\"' else data end, resp_person, serial, refresh,
retry, expire,
minimum from dns_records where zone = '%zone%'}
{select zone from xfr_table where zone = '%zone%' and client =
'%client%'}";
};
I have created a duplicate of one zone in my Postgres database using the
tables described (Though I used "character varying" instead of "text")
When I start "named" (or "named_sdb", whatever that is??), I see no
reference to any attempts to get to the postgres DB. No failures, no
successes, nothing. In another e-mail on the list, I saw logs that
showed the loading of the postgres drivers. I don't see that in my log
files at all?
So . . .
1. Is there something other than the DLZ tag that needs to go into
the named.conf to tell it to use a postgres DB?
2. Is there some library I have not deployed that is required?
3. Should I be running "named" or "named_sdb"?
4. (and my real question) can you have both "zone" and "dlz" tags
in the same named.conf? Our project has a large, static set of DNS
domains and a very small set of dynamic domains. I'd like to be able
to take advantage of the speed of the flat files, and only hit postgres
for for the dynamic sub-domains and still have only one DNS server. If
it can't do this, that will just mean I need both static and dynamic
servers.
Here is what my named.conf file looks like:
options {
directory "/var/named/" ;
allow-transfer { 172.24.2.0/24; 127.0.0.1/8;};
check-names master warn;
datasize 20M;
max-journal-size 5M;
dump-file "named_dump.db";
interface-interval 0;
max-cache-size 20M;
memstatistics-file "/var/stats/named.memstats";
pid-file "/var/run/named.pid";
query-source address * port 53;
transfer-source * port 53;
notify-source * port 53;
statistics-file "/var/stats/named.stats";
version "1.8.0";
zone-statistics yes;
};
logging {
channel named_info {
syslog;
print-category yes;
print-severity yes;
print-time yes;
};
category client { null; };
category config { null; };
category database { null; };
category default { null; };
category general { null; };
category notify { null; };
category network { null; };
category resolver { null; };
category security { null; };
category update { null; };
category queries { null; };
category xfer-in { null; };
category xfer-out { null; };
};
controls {
inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
};
key "rndc-key" {
};
dlz "postgres zone" {
database "postgres 1
{host=int-dbs port=5432 dbname=dns_data user=postgres}
{select zone from dns_records where zone = '%zone%'}
{select ttl, type, mx_priority, case when lower(type)='txt' then '\"'
|| data || '\"' when lower(type)='soa' then data || ' ' ||
resp_person || ' '
|| serial || ' ' || refresh || ' ' || retry || ' ' || expire ||
' ' || minimum
else data end from dns_records where zone = '%zone%' and host =
'%record%'}
{}
{select ttl, type, host, mx_priority, case when lower(type)='txt'
then '\"'
|| data || '\"' else data end, resp_person, serial, refresh,
retry, expire,
minimum from dns_records where zone = '%zone%'}
{select zone from xfr_table where zone = '%zone%' and client =
'%client%'}";
};
zone "." {
type hint;
file "pz/named.root";
};
Michael L. Toler
Sr. System Test Enginee
Re: socket.c:4524: unexpected error
Jeremy C. Reed wrote: On Sat, 9 May 2009, WPPi Photo wrote: I've been seeing more and more of the following errors in all of our name servers running Bind 9.4.3-2 on CentOS 5.3 servers: Is that a CentOS or Red Hat package? Can you provide the spec files for it? It's actually a RPM package that is provided by another vendor that we use on all of our name servers (which run on either CentOS 4.7 (kernel 2.6.9-78.0.22.ELsmp) or CentOS 5.3 (kernel 2.6.18-128.1.10.el5 and kernel 2.6.24-23-xen)). I wasn't able to get a spec file from the rpm and the vendor doesn't offer a SRPM. Does it help if I provide you with a link to the rpm package? Here it is: http://www.psoft.net/shiv/HS/RHES5/hsphere-bind-9.4.3-2.rpm thx, SW ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Several basic questions (and yes, I've looked at the documentation on the web)
You may also want to take this to the DLZ users mailing list, I am
really not sure the correct channel for these questions. I end up
cross posting, which is probably not a good idea.
On May 11, 2009, at 3:25 PM, Mike Toler wrote:
What there is of it. It seems VERY outdated since, if I understand
correctly, DLZ is now built into bind 9.5/9.6.
I have been pretty deep in the DLZ and SDB thing lately as well,
getting ready to get the secondary working now.
I too would like to hear clarification on the difference of DLZ and
SDB. From what I can gather, DLZ was built into BIND a while back, or
support was.
I also, on RHEL, have this SDB thing. On OS X, as a test case, I do
not recall having that, and just added a compile flag through a port
manager to BIND.
The dates on the project are very old. The docs seem accurate,
current, and fine, but a several year old date on anything leads me to
a tiny bit of confusion.
I have downloaded and installed the following RPMs to my DNS server,
which is a VM running RHEL 5.2:
bind-9.5.1-2.P2.el5.pp.x86_64.rpm
bind-libs-9.5.1-2.P2.el5.pp.x86_64.rpm
bind-sdb-9.5.1-2.P2.el5.pp.x86_64.rpm
bind-utils-9.5.1-2.P2.el5.pp.x86_64.rpm
Sounds like you are in the same boat as me, other than I am not in a
VM. Looking over my notes, Here is what I did, maybe you just need to
install the sdb or activate it?
Here is a very condensed form of the notes I took.
yum install libtool
yum install libcap-devel
yum install openldap-devel
yum install postgresql-devel
yum install rpmbuild
rpmbuild -bb /usr/src/redhat/SPECS/bind.spec
* Conidered editing .spec file to remove postgres, ldap and
others, decided
they are good to have, and will be needed by other installs.
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-
libs-9.6.0-2.P1.x86_64.rpm
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-9.6.0-2.P1.x86_64.rpm
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-
utils-9.6.0-2.P1.x86_64.rpm
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-
devel-9.6.0-2.P1.x86_64.rpm
At this point, named will start, with some fiddling, but DLZ
support
is not working
Install the sdb
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-
sdb-9.6.0-2.P1.x86_64.rpm
edited /etc/sysconfig/named
copied /usr/share/doc/bind-9.3.4/sample/etc/* to /etc/
copied /usr/share/doc/bind-9.3.4/sample/var/* to /var/
edited /etc/named.conf
At this point, I ran into SELinux issues, and fought with them.
/etc/selinux/config set to disabled.
To avoid restaring the server: echo 0 > /selinux/enforce
/var/named needs to be named:named
start and stop with sudo /etc/init.d/named start|stop|restart
start by hand:
/usr/sbin/named -f -d 1
-f is foreground, and -d is debug level 1, up if desired
I have added the exact DLZ configuration from the DLZ web page,
other than the IP address and userid for the DB.
I went MySql
dlz "postgres zone" {
database "postgres 1
{host=int-dbs port=5432 dbname=dns_data user=postgres}
{select zone from dns_records where zone = '%zone%'}
{select ttl, type, mx_priority, case when lower(type)='txt' then
'\"'
|| data || '\"' when lower(type)='soa' then data || ' ' ||
resp_person || ' '
|| serial || ' ' || refresh || ' ' || retry || ' ' ||
expire || ' ' || minimum
else data end from dns_records where zone = '%zone%' and
host = '%record%'}
{}
{select ttl, type, host, mx_priority, case when lower(type)='txt'
then '\"'
|| data || '\"' else data end, resp_person, serial,
refresh, retry, expire,
minimum from dns_records where zone = '%zone%'}
{select zone from xfr_table where zone = '%zone%' and client =
'%client%'}";
};
I have created a duplicate of one zone in my Postgres database using
the tables described (Though I used “character varying” instead of
“text”)
When I start “named” (or “named_sdb”, whatever that is??),
You definitely want to make sure you are starting named_sdb, using ps
look for it to confirm.
I see no reference to any attempts to get to the postgres DB. No
failures, no successes, nothing. In another e-mail on the list, I
saw logs that showed the loading of the postgres drivers. I don’t
see that in my log files at all?
What logs are you looking at, on RHEL I see in /var/log/messages I
will get a line of the build flags followed by mentions of each of the
extensions for each database I am able to support.
So . . .
1. Is there something other than the DLZ tag that needs to go
into the named.conf to tell it to use a postgres DB?
No. I have a very normal /etc/named.conf
I got named running before I even tried to get DLZ/SDB working. I
made sure I could return queries to some local text file based zones.
At the bottom of the named.conf file, I added in:
include "dlz_mysql.conf";
In that file, I have the same copy
