Re: catchall, if domain doesn't exist?
On 21.11.10 21:57, Tomasz Chmielewski wrote: > I was wondering if it's possible to return a "catchall" A record for > domains which bind can't resolve? not without patches (I don't know about any). > I'm able to configure a "catchall" bind configuration where bind would > return the same A record for all queries; but I'd rather it returns it > for domains it can't resolve. There's much more in DNS than A records. And you should know that an information "host does not exist" is important in many cases and you could break many applications by doing this. It's also incompatible with DNSSEC. Simply: don't do it. -- 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. 42.7 percent of all statistics are made up on the spot. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio deccio.net> writes: > > After a review of NSEC3 showed that this particular behavior is > expected because org has been signed using NSEC3 with the opt-out bit > set. I'm afraid I'm getting a bit lost due to my real lack of understanding of the details of DNSSEC. I wish I had the time to really sit down and understand the concepts in complete detail. :-( So does the RFC reference just explain why the AD bit (i.e. and not the bigger problem of the spew of log entries from named) is not set or does that explain the entire problem I am seeing (namely the continuous log spew from named)? Cheers, b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Best Practices Query Logging, On or Off ?
On 11/22/2010 01:01 AM, Ben McGinnes wrote: On 22/11/10 5:05 PM, Doug Barton wrote: On 11/21/2010 21:58, Ben McGinnes wrote: On 22/11/10 7:12 AM, Doug Barton wrote: On Thu, 18 Nov 2010, CT wrote: - BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 Really old, definitely needs upgrading. That just means they're running RHEL 5 or CentOS 5. If they have a support contract with Red Hat, they may not be able to upgrade without forfeiting their support and/or certification. That version will include back-ported security fixes. I get that actually. However it doesn't change my recommendation. Even with security patches BIND 9.3 is past EOL, and incapable of doing modern DNSSEC. Fair enough. Red Hat probably need to find a middle ground for proper updates of certain essential packages, like BIND, while working within their upgrade path. That, however, is a topic for another list. Regards, Ben Yeah.. the "other guys" have to run RHEL.. Redhat only supports "their" version of bind.. I used to recompile SRC rpms.. until I went to the ISC class.. now I compile from source.. so so much simpler.. (once you have all the permissions set).. >> - BIND 9.7.1-P2 > Not the latest version, you should probably consider upgrading. I haven't really read the change log yet... but most likely will Charles ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
How rndc flushname a TXT or SPF record?
Dear Folks, It's easy enough to flush an A or PTR record with rndc flushname name. But how do you flush a TXT or SPF record? (I don't want to flush the whole zone). -- Nick Urbanik http://nicku.org ni...@nicku.org GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How rndc flushname a TXT or SPF record?
On 23/11/10 06:55 +1100, Nick Urbanik wrote: Dear Folks, It's easy enough to flush an A or PTR record with rndc flushname name. But how do you flush a TXT or SPF record? (I don't want to flush the whole zone). Simple! Just rndc flushname domainname works. -- Nick Urbanik http://nicku.org ni...@nicku.org GPG: 7FFA CDC7 5A77 0558 DC7A 790A 16DF EC5B BB9D 2C24 ID: BB9D2C24 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: How rndc flushname a TXT or SPF record?
On Nov 22 2010, Nick Urbanik wrote: Dear Folks, It's easy enough to flush an A or PTR record with rndc flushname name. But how do you flush a TXT or SPF record? Exactly the same way. (I don't want to flush the whole zone). There isn't any "flush whole zone" function in BIND. "rndc flush" discards the entire cache. "rndc flushname [name]" discards all records with that specific name, regardless of type. (All this per-view, if you use views.) -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
internal named crash, dnssec-validation bug?
Hello, We are running bind-9.7.2-P2 with dnssec-validation enabled for our internal nameservers, and our internal nameservers crashed at the time of reload around 2-4pm EST, one the nameserver with dnssec debug log enabled shows tons of 'deadlock error' for some of the sub-domains under .fr, like this: 20-Nov-2010 15:17:51.642 dnssec: debug 3: validating @0x13419450: multimania.fr DS: continuing validation would lead to deadlock: aborting validation 20-Nov-2010 15:17:51.642 dnssec: debug 3: validating @0x13419450: multimania.fr DS: deadlock found (create_fetch) And here is the core dump: ... Core was generated by `/usr/local/sbin/named -u named -t /usr/local/jail/dns/ -c /named/named.conf'. Program terminated with signal 11, Segmentation fault. #0 0x2b948048691c in validated (task=, event=0x2aaab2b8edb8) at resolver.c:4013 4013isc_mem_put(fctx->res->buckets[fctx->bucketnum].mctx, (gdb) backtrace #0 0x2b948048691c in validated (task=, event=0x2aaab2b8edb8) at resolver.c:4013 #1 0x2b9480d89eac in dispatch (uap=0x2b94811c6010) at task.c:1013 #2 run (uap=0x2b94811c6010) at task.c:1158 #3 0x003b31e06617 in start_thread () from /lib64/libpthread.so.0 #4 0x003b316d3c2d in clone () from /lib64/libc.so.6 It happened two month ago when .uk domain validation failed bacause of ZSK roll-over problem: Sep 11 12:00:31 nameserver kernel: named[15795] general protection rip:2aaab72a0fac rsp:41b97030 error:0 11-Sep-2010 12:00:02.779 dnssec: debug 3: validating @0x2aaabf53c790: u1fmklfv3rdcnamdc64sekgcdp05bbiu.uk NSEC3: continuing validation would lea d to deadlock: aborting validation 11-Sep-2010 12:00:02.779 dnssec: debug 3: validating @0x2aaabf53c790: u1fmklfv3rdcnamdc64sekgcdp05bbiu.uk NSEC3: deadlock found (create_fetch) Thanks, Sue ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Summary: problem getting address record for google public dns server
Thanks to both Stacey and Barry for the feedback. You've answered my question. Sorry I didn't get back with you on this sooner! Marty Date: Wed, 17 Nov 2010 10:01:13 + From: stacey.marsh...@oracle.com To: bind-users@lists.isc.org Subject: Re: problem getting address record for google public dns server This crops up time and time again - perhaps +trace should have been +mimic. The '+trace' option causes dig to act as a recursive server would, asking each server in turn for a none recursive answer. Thus when you say +trace its your instance of dig that's doing the work. The details in the response hold your answer: $ dig @66.231.91.222 google-public-dns-a.google.com ; <<>> DiG 9.3.6-P1 <<>> @66.231.91.222 google-public-dns-a.google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 503 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;google-public-dns-a.google.com.IN A ;; AUTHORITY SECTION: . 360 IN NS A.ROOT-SERVERS.NET. . 360 IN NS B.ROOT-SERVERS.NET. . 360 IN NS C.ROOT-SERVERS.NET. . 360 IN NS D.ROOT-SERVERS.NET. . 360 IN NS E.ROOT-SERVERS.NET. . 360 IN NS F.ROOT-SERVERS.NET. . 360 IN NS G.ROOT-SERVERS.NET. . 360 IN NS H.ROOT-SERVERS.NET. . 360 IN NS I.ROOT-SERVERS.NET. . 360 IN NS J.ROOT-SERVERS.NET. . 360 IN NS K.ROOT-SERVERS.NET. . 360 IN NS L.ROOT-SERVERS.NET. . 360 IN NS M.ROOT-SERVERS.NET. ;; Query time: 111 msec ;; SERVER: 66.231.91.222#53(66.231.91.222) ;; WHEN: Wed Nov 17 09:50:35 2010 ;; MSG SIZE rcvd: 259 Looking at the flags in the response note the lack of 'ra'; Recursion Available! Thus the server is saying I don't know (or I wont tell you what's in my cache) and I'm not going to find an answer for you, go start looking at the root servers. Hence the +trace works. Regards Stacey On 16/11/2010 21:00, M. Meadows wrote: Can someone explain the following dig results? The first dig @8.8.8.8 provides the expected result : dig +noall +answer google-public-dns-a.google.com @8.8.8.8 google-public-dns-a.google.com. 85040 IN A 8.8.8.8 We get the same result from KLOTH.NET (http://www.kloth.net/services/nslookup.php) But when we specify the public facing exacttarget.com server : dig +noall +answer google-public-dns-a.google.com @66.231.91.222 No answer And when we use +trace ... it seems to find it's way to the correct answer. : dig google-public-dns-a.google.com @66.231.91.222 +trace ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> google-public-dns-a.google.com @66.231.91.222 +trace ;; global options: printcmd . 360 IN NS A.ROOT-SERVERS.NET. . 360 IN NS B.ROOT-SERVERS.NET. . 360 IN NS C.ROOT-SERVERS.NET. . 360 IN NS D.ROOT-SERVERS.NET. . 360 IN NS E.ROOT-SERVERS.NET. . 360 IN NS F.ROOT-SERVERS.NET. . 360 IN NS G.ROOT-SERVERS.NET. . 360 IN NS H.ROOT-SERVERS.NET. . 360 IN NS I.ROOT-SERVERS.NET. . 360 IN NS J.ROOT-SERVERS.NET. . 360 IN NS K.ROOT-SERVERS.NET. . 360 IN NS L.ROOT-SERVERS.NET. . 360 IN NS M.ROOT-SERVERS.NET. ;; Received 228 bytes from 66.231.91.222#53(66.231.91.222) in 1 ms com.172800 IN NS g.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS a.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. ;; Received 504 bytes from 198.41.0.4#53(A.
Re: catchall, if domain doesn't exist?
On 11/21/2010 3:57 PM, Tomasz Chmielewski wrote: I was wondering if it's possible to return a "catchall" A record for domains which bind can't resolve? I'm able to configure a "catchall" bind configuration where bind would return the same A record for all queries; but I'd rather it returns it for domains it can't resolve. It's evil, don't do it: http://www.google.com/search?q=nxdomain+redirection - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
On Mon, Nov 22, 2010 at 5:28 AM, Brian J. Murrell wrote: > Casey Deccio deccio.net> writes: >> >> After a review of NSEC3 showed that this particular behavior is >> expected because org has been signed using NSEC3 with the opt-out bit >> set. > > I'm afraid I'm getting a bit lost due to my real lack of understanding of the > details of DNSSEC. I wish I had the time to really sit down and understand > the > concepts in complete detail. :-( > > So does the RFC reference just explain why the AD bit (i.e. and not the bigger > problem of the spew of log entries from named) is not set yes, I was clarifying that my particular observation with respect to the AD bit was not a useful insight into troubleshooting the other issues. > or does that explain > the entire problem I am seeing (namely the continuous log spew from named)? > I still don't have the answer to this. Perhaps a BIND developer may have better insight into the log messages and what may be going on. Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dynamic updates via libbind.
I was unclear. I know that libbind is its own package. It was spun off some time ago, and no work has been released on it is since. I was asking if perhaps there was something in the works that is replacing it. And the answer to that is, apparently, no. Thanks > -Original Message- > From: Doug Barton [mailto:do...@dougbarton.us] > Sent: Sunday, November 21, 2010 1:41 PM > To: Jack Tavares > Cc: bind-users@lists.isc.org > Subject: Re: dynamic updates via libbind. > > On Fri, 12 Nov 2010, Jack Tavares wrote: > > > I am currently using libbind to do dynamic updates in "C". > > > > I have looked in the bind 9.7.x source and I don't see a replacement > mechanism for this. > > libbind is now its own package, separate from the BIND sources. Look > carefully on the ISC web page under software (IIRC). > > > hth, > > Doug > > -- > > Nothin' ever doesn't change, but nothin' changes much. > -- OK Go > > Breadth of IT experience, and depth of knowledge in the DNS. > Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dynamic updates via libbind.
On 11/22/2010 13:57, Jack Tavares wrote: And the answer to that is, apparently, no. I don't speak for ISC so you should not take my statement(s) as relevant to the future of what may or may not happen with libbind. Meanwhile, is your question based on idle curiosity, or is there some specific problem that you're trying to address? If yes, perhaps starting over with a fresh thread that describes the problem you're having would be a good way to proceed. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
can @ be CNAME?
Hello, can I set @ to a cname type? like: @ IN CNAME www.example.com. Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: can @ be CNAME?
On 23.11.10 15:50, Tech W. wrote: > can I set @ to a cname type? like: > > @ IN CNAME www.example.com. Certainly not. for a domain you have you need SOA and NS records, and CNAME is incompatible with both of them. OF course you can do $ORIGIN new.example.com. @ IN CNAME www.example.com. but that's apparently not your case -- 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. Honk if you love peace and quiet. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
