Re: Trying to understand DNSSEC and BIND versions better
On Jun 10, 2009, at 7:01 PM, Chris Adams wrote: Once upon a time, Chris Buxton said: On the other hand, the builds from the Linux vendors have been less than perfectly stable at moderately high levels of traffic. Rebuilding from stock source code has always fixed this problem. We've seen this problem with both the Red Hat build and the Debian build. What do you mean by "moderately high levels of traffic"? We run RHEL 5 and its build of BIND with no troubles. I don't really see anything in the source RPM for BIND that would cause it to be any more or less stable than a build from the standard distribution (modulo stability bugs in specific BIND versions itself). I can't really be any more specific than I have been - the servers in question are not our servers, and I'm not able to analyze the source code of the patches and of BIND to see what might be causing problems. A few of our customers, running servers that they describe as experiencing high traffic (by their own standards), have had to have us rebuild BIND from the stock source code for them to solve frequent crashing during such high traffic episodes. Frequent in this case typically means that named either just dies or dumps core within a few seconds of starting up. The Red Hat BIND SRPM applies a variety of patches that have been back- ported from later versions. These patches appear to not be 100% compatible with the older code they use as a base. When we have torn apart the SRPM, replacing the base source code and disabling all patches except the one that changes the path to the PID files, and then rebuilt the RPM, the result has been able to hold up for these customers. In such cases, we're not changing the configure options, we're installing the result on the same servers that are falling over with the RH-supplied version, and the result is a server that runs and doesn't crash or dump core. We have not bothered to build a .deb package for Ubuntu, just compiled the stock source code with fairly standard options. Again, this has always solved the problem for the affected customers. One such case was the most reliable at producing rapid core dumps that I have personally seen, until we upgraded them. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
Once upon a time, Chris Buxton said: > On the other hand, the builds from the Linux vendors have been less > than perfectly stable at moderately high levels of traffic. Rebuilding > from stock source code has always fixed this problem. We've seen this > problem with both the Red Hat build and the Debian build. What do you mean by "moderately high levels of traffic"? We run RHEL 5 and its build of BIND with no troubles. I don't really see anything in the source RPM for BIND that would cause it to be any more or less stable than a build from the standard distribution (modulo stability bugs in specific BIND versions itself). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
On Jun 9, 2009, at 5:21 PM, Mark Andrews wrote: In message <20090609113700.ga6...@evileye.atkac.englab.brq.redhat.com>, Adam Tk ac writes: On Tue, Jun 09, 2009 at 11:22:12AM +1000, Mark Andrews wrote: In message <99e6a67a9da87041a8020fbc11f480b3031cc...@exvs01.dsw.net>, "Jeff Lig htner" writes: BIND versions on RHEL (e.g. 9.3.4-6.0.3.P1.el5_2) have backported patches from later BIND versions so it isn't exactly the same animal as the EOL 9.3 which is why it isn't listed simply as 9.3 I've yet to see a vendor back port every bug fix and that is what would be required to really support a product in a OS which is at EOL by the producer. Mark This is neverending discord between you (upstream) and vendors. You are right the ideal approach is to backport all fixes but it simply consumes much manpower. Update to newer version is not possible because there are configuration incompatibilities. Optimal software from economic perspective is usually different from optimal software from programming perspective. If you combine both perspectives you probably get answer why vendors backport patches only for issues which are reported by their customers. Regards, Adam There are very few backwards compatiblilty issues with BIND in terms of configuration files. If you ignore the logging stanza you should be able take most BIND 8.1 configuration files and have BIND 9.6.1 use it. There are even tools in the distribution to take a BIND 4 configuration file and convert it to BIND 8/9 format and use it. The master files go back to the earliest version of BIND 4. New version are just less tolerent of errors in the master files. Correct master files from 2 decades ago just work. Almost all the changes in major revisions is new functionality. The change to the default value of allow-recursion is still tripping up our customers. Otherwise, I agree. On the other hand, the builds from the Linux vendors have been less than perfectly stable at moderately high levels of traffic. Rebuilding from stock source code has always fixed this problem. We've seen this problem with both the Red Hat build and the Debian build. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clients sometimes get wrong view
Is there any chance that stub resolver caching is at work here? For
example, if someone is in the datacenter, uses a name in some way, and
then moves to the office, it's conceivable that their stub resolver
will hang onto the datacenter address for the name. A simple test for
this would be to clear the cache and try again, the next time the
symptom presents - if that solves it, then the problem has nothing to
do with your name server's configuration.
If that's the problem, then use of short TTL's in the private
namespaces (datacenter, in this case) would help.
Chris Buxton
Professional Services
Men & Mice
On Jun 9, 2009, at 1:17 PM, Corey Shaw wrote:
Thanks Kevin and Jeff for your answers.
I will try adding logging so that I can see exactly what view is
matched.
Also, yes, mydomain.com is listed in the include files that I did
not provide. It is listed in each of the different views. This is
how it had to be set up, because Bind does not provide more than one
view per query (ie. If the domain doesn't exist in "office" view,
it will not go to the "datacenter" view to look next). Each view
potentially has a different address for mydomain.com depending on
whether that is local to them or not. In my case, mydomain.com
should be a public address for the "office" view, and an internal
address for the "datacenter" view
I have experienced this issue myself here at our office which falls
in the 166.x.x.88/29 (office) view. Somehow, I ended up getting a
result from the 10.x.x.0/24 (datacenter) view. The only possible IP
address that comes from our office lies in the 166.x.x.88/29 view
range. Yes, I know that it isn't terribly efficient for my DNS
servers to not be local to my office, but I haven't gotten around to
adding caching servers locally yet.
_
Corey
- Original Message -
From: "Kevin Darcy"
To: bind-users@lists.isc.org
Sent: Tuesday, June 9, 2009 1:49:54 PM GMT -07:00 US/Canada Mountain
Subject: Re: Clients sometimes get wrong view
Note that the newer versions of querylog format include not only the
source address of the client, but also what view was *actually*
matched
by the query. It should be useful to turn on the querylog for
troubleshooting this particular issue, if the volume of queries
isn't so
huge that you'd run into capacity issues...
- Kevin
Jeff Lightner wrote:
>
> It seems the mydomain.com isn’t in the view but presumably in one of
> the includes.
>
> So the most likely issues seem to be:
>
> 1) You have defined mydomain.com in more than one of the includes
> which we can’t tell since you didn’t provide them.
>
> –OR-
>
> 2) The client actually has an unexpected IP (that is you think they
> are in the 10.x when they are actually in 192.x or vice-versa or
they
> don’t have an IP in either of the ranges you specified.
>
>
>
> *From:* bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] *On Behalf Of *Corey Shaw
> *Sent:* Tuesday, June 09, 2009 1:56 PM
> *To:* bind-users@lists.isc.org
> *Subject:* Clients sometimes get wrong view
>
> OS: Gentoo
>
> Bind Version: 9.6.0-p1
>
> I currently have my Bind server set up with 3 views. It seems that
> every now and then I have clients in the "office" view that try to
go
> to www.mydomain.com (which should be a public address), but instead
> they get the internal address that is defined in the "datacenter"
view
> (10.x.x.x). As a result, they can't get to www.mydomain.com. My
views
> are configured as shown below (yes, all the include files exist and
> load properly). They are ordered in my configuration as shown
below as
> well. Any ideas on why this may be happening?
>
> view "datacenter" {
>
> match-clients { 10.x.x.0/24; };
>
> recursion yes;
>
> include "/etc/bind/includes/datacenterincludes.conf";
>
> allow-recursion { 10.x.x.0/24; };
>
> zone "." IN {
>
> type hint;
>
> file "named.ca";
>
> };
>
> zone "localhost" IN {
>
> type master;
>
> file "pri/localhost.zone";
>
> allow-update { none; };
>
> notify no;
>
> };
>
> zone "127.in-addr.arpa" IN {
>
> type master;
>
> file "pri/127.zone";
>
> allow-update { none; };
>
> notify no;
>
> };
>
> };
>
> view "office" {
>
> match-clients { 166.x.x.88/29; };
>
> recursion yes;
>
> include "/etc/bind/includes/officeincludes.conf";
>
> allow-recursion { 166.x.x.88/29; };
>
> zone "." IN {
>
> type hint;
>
> file "named.ca";
>
> };
>
> zone "localhost" IN {
>
> type master;
>
> file "pri/localhost.zone";
>
> allow-update { none; };
>
> notify no;
>
> };
>
> zone "127.in-addr.arpa" IN {
>
> type master;
>
> file "pri/127.zone";
>
> allow-update { none; };
>
> notify no;
>
> };
>
> };
>
> view "public" {
>
> match-clients { any; };
>
> recursion no;
>
> include "/etc/bind/includes/publicincludes.conf";
>
> allow-recursion { none; };
>
> zone "." IN {
>
> type hint;
>
> file "named.ca";
>
> };
>
Re: Issue with reverse dns and local caching name server
In message <4a2fcb63.8030...@easysoft.com>, Jason Crummack writes:
> Kirk wrote:
> >> $ dig +trace @127.0.0.1 -x 203.22.30.47
> >>
> >> ; <<>> DiG 9.4.3 <<>> +trace @127.0.0.1 -x 203.22.30.47
> >> ; (1 server found)
> >> ;; global options: printcmd
> >> . 517909 IN NS G.ROOT-SERVERS.NET.
> >> . 517909 IN NS A.ROOT-SERVERS.NET.
> >> . 517909 IN NS B.ROOT-SERVERS.NET.
> >> . 517909 IN NS K.ROOT-SERVERS.NET.
> >> . 517909 IN NS J.ROOT-SERVERS.NET.
> >> . 517909 IN NS M.ROOT-SERVERS.NET.
> >> . 517909 IN NS H.ROOT-SERVERS.NET.
> >> . 517909 IN NS L.ROOT-SERVERS.NET.
> >> . 517909 IN NS C.ROOT-SERVERS.NET.
> >> . 517909 IN NS I.ROOT-SERVERS.NET.
> >> . 517909 IN NS E.ROOT-SERVERS.NET.
> >> . 517909 IN NS F.ROOT-SERVERS.NET.
> >> . 517909 IN NS D.ROOT-SERVERS.NET.
> >> ;; Received 492 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
> >>
> >> 203.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET.
> >> 203.in-addr.arpa. 86400 IN NS NS-SEC.RIPE.NET.
> >> 203.in-addr.arpa. 86400 IN NS NS4.APNIC.NET.
> >> 203.in-addr.arpa. 86400 IN NS DNS1.TELSTRA.NET.
> >> 203.in-addr.arpa. 86400 IN NS NS1.APNIC.NET.
> >> 203.in-addr.arpa. 86400 IN NS NS3.APNIC.NET.
> >> ;; Received 185 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 273 ms
> >>
> >> 30.22.203.in-addr.arpa. 86400 IN NS ns.bigtrolley.com.au.
> >> 30.22.203.in-addr.arpa. 86400 IN NS ns.opensystems.com.au.
> >> ;; Received 106 bytes from 193.0.0.196#53(NS-SEC.RIPE.NET) in 26 ms
Nameservers cannot be CNAME's. Named does not follow CNAME's
as they cannot be made to work in all configuration so it
is better make all uses fail than just those that won't
work. For CNAME's to work you would have to register both
the CNAME and the glue address records in the parent and
have the additional section processing rules follow CNAME's.
To fix this go to APNIC and register ns01.opensystems.com.au
and ns02.opensystems.com.au as the nameservers for
30.22.203.in-addr.arpa. What is in the parent zone should
be copies of what is in the child zone.
Mark
; <<>> DiG 9.3.6-P1 <<>> ns.opensystems.com.au
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57002
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;ns.opensystems.com.au. IN A
;; ANSWER SECTION:
ns.opensystems.com.au. 38167 IN CNAME ns01.opensystems.com.au.
ns01.opensystems.com.au. 38168 IN A 203.22.30.35
;; AUTHORITY SECTION:
opensystems.com.au. 14150 IN NS ns02.opensystems.com.au.
opensystems.com.au. 14150 IN NS ns01.opensystems.com.au.
;; ADDITIONAL SECTION:
ns02.opensystems.com.au. 38167 IN A 203.22.30.26
;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 11 08:42:24 2009
;; MSG SIZE rcvd: 123
; <<>> DiG 9.3.6-P1 <<>> ns.bigtrolley.com.au.
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65112
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; QUESTION SECTION:
;ns.bigtrolley.com.au. IN A
;; ANSWER SECTION:
ns.bigtrolley.com.au. 38182 IN CNAME ns02.opensystems.com.au.
ns02.opensystems.com.au. 38182 IN A 203.22.30.26
;; AUTHORITY SECTION:
opensystems.com.au. 14165 IN NS ns01.opensystems.com.au.
opensystems.com.au. 14165 IN NS ns02.opensystems.com.au.
;; ADDITIONAL SECTION:
ns01.opensystems.com.au. 38183 IN A 203.22.30.35
;; Query time: 7 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 11 08:42:09 2009
;; MSG SIZE rcvd: 134
> >>
> >> 47.30.22.203.in-addr.arpa. 38400 IN PTR mail.opensystems.com.au.
> >> 30.22.203.in-addr.arpa. 38400 IN NS ns02.opensystems.com.au.
> >> 30.22.203.in-addr.arpa. 38400 IN NS ns01.opensystems.com.au.
> >> ;; Received 150 bytes from 203.22.30.26#53(ns.bigtrolley.com.au) in
> >> 326 ms
> >>
> >>
> >
> > Not sure I'm correct here, but wondering if this has something to do
> > with:
> > ns.opensystems.com.au. is aliased to ns01.opensystems.com.au.
> > ns.bigtrolley.com.au. is aliased to ns02.opensystems.com.au.
> >
> >
> >> running bind version 9.4.3
> >>
> >> named.conf
> >> <<<
> >> options {
> >> directory "/var/named";
> >> query-source address 192.168.0.15 port 53;
> >
> > Off top
Nicht erreichbar bis 22.06.2009 / Out of Office until 06/22/2009
Ich werde ab 30.05.2009 nicht im Büro sein. Ich kehre zurück am 22.06.2009. Danke für Ihre E-Mail-Nachricht. Ich bin bis 22. Juni 2009 nicht im Büro. In dringenden Angelegenheiten kontaktieren Sie bitte DENIC IT-Services (E-Mail: i...@denic.de, Tel: (069) 27235-160 oder -250). - Thank you for your email message. I am not in the office until 22 June 2009. In urgent cases please contact DENIC IT-Services (e-mail: i...@denic.de, Tel: +49 69 27235-160 or -250). -- Joachim Strohbach Leiter IT-Services / Head of IT-Services DENIC eG Kaiserstraße 75-77 60329 Frankfurt am Main GERMANY E-Mail: strohb...@denic.de Fon: +49 69 27235-123 / -371 Fon: +49 69 27235-160 (Assistance) Fon: +49 69 27235-250 (IT-Services) Fax: +49 69 27235-239 SIP-URI: sip:1...@denic.de http://www.denic.de PGP-KeyID: 0x7A8A00FF, Fingerprint: 30AB 0F15 17D3 995F CA50 F0A8 EA30 B915 7A8A 00FF Angaben nach § 25a Absatz 1 GenG: DENIC Domain Verwaltungs- und Betriebsgesellschaft eG (Sitz: Frankfurt am Main) Vorstand: Sabine Dolderer, Marcus Schäfer, Carsten Schiefner, Dr. Jörg Schweiger Vorsitzender des Aufsichtsrats: Elmar Knipp Eingetragen unter Nr. 770 im Genossenschaftsregister, Amtsgericht Frankfurt am Main ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Changing CHROOT at BIND compile time
Please ignore me - I realized too late that someone else was installing BIND as I was compiling, and that created the directory I was seeing. I realize now that BIND wouldn't be creating this ... it was silly of me to assume that. Cheers, Todd. -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder Sent: Wednesday, June 10, 2009 11:45 AM To: bind-users@lists.isc.org Subject: Changing CHROOT at BIND compile time Good day, I am working at building BIND, and I will admit right now that I am not much of a developer. I noticed that when you compile/make/install BIND, it creates /var/named/chroot as the default chroot jail. We don't use that particular standard, and have been simply moving things afterwards. However, I'm wondering if there is a way to define, at compile time, where the chroot will be created, so that we don't have to do the intermediate movement step? I've been trying to dig through the configure script, and through the Makefile to find this, but as I said before, I'm not much of a developer, and I'm not really familiar with the processes. I'm guessing that there must be a way to change this, as everything is just makefiles/source at compile time, but I am not sure where to look. Thanks much, Todd. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Changing CHROOT at BIND compile time
On Wed, 10 Jun 2009, Todd Snyder wrote: > I am working at building BIND, and I will admit right now that I am not > much of a developer. I noticed that when you compile/make/install BIND, > it creates /var/named/chroot as the default chroot jail. We don't use > that particular standard, and have been simply moving things afterwards. BIND doesn't create a chroot directory. BIND doesn't have a default chroot directory. I think you are seeing that from something else. > However, I'm wondering if there is a way to define, at compile time, > where the chroot will be created, so that we don't have to do the > intermediate movement step? I've been trying to dig through the > configure script, and through the Makefile to find this, but as I said > before, I'm not much of a developer, and I'm not really familiar with > the processes. > > I'm guessing that there must be a way to change this, as everything is > just makefiles/source at compile time, but I am not sure where to look. named doesn't create the chroot directory. The chroot directory is defined on the named command line with -t switch. We currently don't have option to define this at compile time. Start looking at the ns_g_chrootdir in the code. Jeremy C. Reed ISC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: queries with no RD bit set are truncating
Peter Andreev wrote: Good day I have met a trouble with non-recursive BIND 9.3.3, running on FreeBSD 6.2-R. Sometimes if one of our clients sends query with no RD bit set, he receives a truncated answer. If RD bit is set then all well. Where I should look to localise a problem? By "non-recursive" do you mean that recursion is turned completely *off* and the response is coming from a zone for which you are authoritative (master or slave)? If so, I can't believe that there would be a difference between the responses to a RD=0 versus a RD=1 query. I'd suggest duplicating the problem by making the same queries manually. Run a sniffer trace if necessary. My suspicion is that your "non-recursive" server isn't completely "non-recursive", and the RD=1 queries in question might be fetching data sets from remote, authoritative servers (e.g. chasing aliases), which happen to be smaller than the delegation sets that would be returned in a referral response in the RD=0 case. That would explain why the RD=0 query truncates and the RD=1 query doesn't (because NS records are *necessary* in a referral response, but *optional* in other types of responses, unless QTYPE=NS; TC is only set when the full set of *necessary* records doesn't fit into the response). If you have delegation sets that are so large that they don't fit in a "classic" 512-byte DNS response, then in my opinion you should probably review whether all of those NS records are really necessary, and prune the list(s) down. In any case, why is this really an issue, except perhaps from a performance/capacity standpoint (which hardly seems the case since you said this only happens "sometimes")? The client retries via TCP, and almost certainly gets the full answer it was looking for. The only way to get truncation on a TCP query is if you hit the 64K limit, but that seems highly unlikely. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Changing CHROOT at BIND compile time
Good day, I am working at building BIND, and I will admit right now that I am not much of a developer. I noticed that when you compile/make/install BIND, it creates /var/named/chroot as the default chroot jail. We don't use that particular standard, and have been simply moving things afterwards. However, I'm wondering if there is a way to define, at compile time, where the chroot will be created, so that we don't have to do the intermediate movement step? I've been trying to dig through the configure script, and through the Makefile to find this, but as I said before, I'm not much of a developer, and I'm not really familiar with the processes. I'm guessing that there must be a way to change this, as everything is just makefiles/source at compile time, but I am not sure where to look. Thanks much, Todd. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND not talking to syslog daemon
On Jun 10 2009, Todd Snyder wrote:
I have a nameserver running BIND 9.3.5-p1 that doesn't want to log to
the syslog daemon. I have 2 identically configured servers, one of them
works, one doesn't.
My logging configuration looks like:
category default{ my_default; default_syslog;
default_debug; };
I don't have a channel defined for "default_syslog" which means the
daemon should be using the built-in channel, as I understand it.
While logs are seen in "my_default", they are just not showing up in
syslog. We have restarted syslog-ng and verified the configuration,
it's the same as the working unit.
Maybe it's as simple as the severity cutoff in your syslog.conf
(for category "daemon", from the default_syslog channel) not
letting the messages through? What severity are the messages you
are seeing via my_default? (Add a "print-severity yes;" to its
definition if you haven't already.)
Syslog works otherwise on the box from other daemons, just not named.
Our thought is that for some reason the named daemon can't connect to
syslog, or gave up trying.
We cannot reload named on the box right now, so I am looking to see if
anyone has suggestions about what might be causing this, and/or ways to
resolve it without restarting the named daemon.
You never need to restart named. (Well, hardly ever.) You can change
the logging configuration in named.conf, check your syntax with
named-checkconf, and put it into effect with "rndc reconfig".
--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
queries with no RD bit set are truncating
Good day I have met a trouble with non-recursive BIND 9.3.3, running on FreeBSD 6.2-R. Sometimes if one of our clients sends query with no RD bit set, he receives a truncated answer. If RD bit is set then all well. Where I should look to localise a problem? Thank you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with reverse dns and local caching name server
Kirk wrote:
$ dig +trace @127.0.0.1 -x 203.22.30.47
; <<>> DiG 9.4.3 <<>> +trace @127.0.0.1 -x 203.22.30.47
; (1 server found)
;; global options: printcmd
. 517909 IN NS G.ROOT-SERVERS.NET.
. 517909 IN NS A.ROOT-SERVERS.NET.
. 517909 IN NS B.ROOT-SERVERS.NET.
. 517909 IN NS K.ROOT-SERVERS.NET.
. 517909 IN NS J.ROOT-SERVERS.NET.
. 517909 IN NS M.ROOT-SERVERS.NET.
. 517909 IN NS H.ROOT-SERVERS.NET.
. 517909 IN NS L.ROOT-SERVERS.NET.
. 517909 IN NS C.ROOT-SERVERS.NET.
. 517909 IN NS I.ROOT-SERVERS.NET.
. 517909 IN NS E.ROOT-SERVERS.NET.
. 517909 IN NS F.ROOT-SERVERS.NET.
. 517909 IN NS D.ROOT-SERVERS.NET.
;; Received 492 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
203.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET.
203.in-addr.arpa. 86400 IN NS NS-SEC.RIPE.NET.
203.in-addr.arpa. 86400 IN NS NS4.APNIC.NET.
203.in-addr.arpa. 86400 IN NS DNS1.TELSTRA.NET.
203.in-addr.arpa. 86400 IN NS NS1.APNIC.NET.
203.in-addr.arpa. 86400 IN NS NS3.APNIC.NET.
;; Received 185 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 273 ms
30.22.203.in-addr.arpa. 86400 IN NS ns.bigtrolley.com.au.
30.22.203.in-addr.arpa. 86400 IN NS ns.opensystems.com.au.
;; Received 106 bytes from 193.0.0.196#53(NS-SEC.RIPE.NET) in 26 ms
47.30.22.203.in-addr.arpa. 38400 IN PTR mail.opensystems.com.au.
30.22.203.in-addr.arpa. 38400 IN NS ns02.opensystems.com.au.
30.22.203.in-addr.arpa. 38400 IN NS ns01.opensystems.com.au.
;; Received 150 bytes from 203.22.30.26#53(ns.bigtrolley.com.au) in
326 ms
Not sure I'm correct here, but wondering if this has something to do
with:
ns.opensystems.com.au. is aliased to ns01.opensystems.com.au.
ns.bigtrolley.com.au. is aliased to ns02.opensystems.com.au.
running bind version 9.4.3
named.conf
<<<
options {
directory "/var/named";
query-source address 192.168.0.15 port 53;
Off topic, I thought setting a query-source port is a bad thing with
regards to DNS cache poisoning attacks.
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };
};
logging {
category lame-servers { null; };
};
# main root caches
zone "." {
type hint;
file "root.cache";
};
>>>
Thanks for the heads up on the query-source port kirk will remove it.
Found out that the name servers that our hosting provider has (the ones
that work) use a simpleDNS cluster so guessing maybe they work by not
being as strict on name reversing as bind is.
Jason
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND not talking to syslog daemon
What OS?
On RHEL5 I have to set options in /etc/sysconfig/syslog (separate from
/etc/syslog.conf) like this:
SYSLOGD_OPTIONS="-m 0 -a /var/named/chroot/dev/log"
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
Sent: Wednesday, June 10, 2009 10:17 AM
To: bind-users@lists.isc.org
Subject: BIND not talking to syslog daemon
Good day,
I've run into a bit of an oddity, and I'm hoping someone might have an
idea.
I have a nameserver running BIND 9.3.5-p1 that doesn't want to log to
the syslog daemon. I have 2 identically configured servers, one of them
works, one doesn't.
My logging configuration looks like:
category default{ my_default; default_syslog;
default_debug; };
I don't have a channel defined for "default_syslog" which means the
daemon should be using the built-in channel, as I understand it.
While logs are seen in "my_default", they are just not showing up in
syslog. We have restarted syslog-ng and verified the configuration,
it's the same as the working unit.
Syslog works otherwise on the box from other daemons, just not named.
Our thought is that for some reason the named daemon can't connect to
syslog, or gave up trying.
We cannot reload named on the box right now, so I am looking to see if
anyone has suggestions about what might be causing this, and/or ways to
resolve it without restarting the named daemon.
Thanks in advance,
Todd.
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
BIND not talking to syslog daemon
Good day,
I've run into a bit of an oddity, and I'm hoping someone might have an
idea.
I have a nameserver running BIND 9.3.5-p1 that doesn't want to log to
the syslog daemon. I have 2 identically configured servers, one of them
works, one doesn't.
My logging configuration looks like:
category default{ my_default; default_syslog;
default_debug; };
I don't have a channel defined for "default_syslog" which means the
daemon should be using the built-in channel, as I understand it.
While logs are seen in "my_default", they are just not showing up in
syslog. We have restarted syslog-ng and verified the configuration,
it's the same as the working unit.
Syslog works otherwise on the box from other daemons, just not named.
Our thought is that for some reason the named daemon can't connect to
syslog, or gave up trying.
We cannot reload named on the box right now, so I am looking to see if
anyone has suggestions about what might be causing this, and/or ways to
resolve it without restarting the named daemon.
Thanks in advance,
Todd.
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with reverse dns and local caching name server
Noel Butler wrote: On Wed, 2009-06-10 at 11:20 +0100, Jason Crummack wrote: dig @82.138.243.4 30.22.203.in-addr.arpa NS I get a response from that IP as well, however from mine, I don't, I suspect that's the server cache. Is this IP range still delegated to you? dig 30.22.203.in-addr.arpa NS ; <<>> DiG 9.4.2-P2 <<>> 30.22.203.in-addr.arpa NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14148 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa. IN NS I get a response from that as well, however from mine, I don't, I suspect thats the server cache Is this IP range still delegated to you?/ dig 30.22.203.in-addr.arpa NS ; <<>> DiG 9.4.2-P2 <<>> 30.22.203.in-addr.arpa NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14148 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa. IN NS dig 47.30.22.203.in-addr.arpa @ns01.opensystems.com.au. ; <<>> DiG 9.4.2-P2 <<>> 47.30.22.203.in-addr.arpa @ns01.opensystems.com.au. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 413 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;47.30.22.203.in-addr.arpa. IN A ;; AUTHORITY SECTION: 30.22.203.in-addr.arpa. 38400 IN SOA ns01.opensystems.com.au. support.opensystems.com.au. 1052091109 10800 3600 604800 38400 Querying your server gets a response, but like mine, none others seem to, what changes have you made recently? a Te$ltra server I query also knows it, but my secondary DNS (located in California) does not either, nor does ns1.exetel so somethings changed None of the servers listed other than my local caching lookup server belong to us / are maintained by us. The 47.30.22.203 is a customer of ours who's email into our domain is being rejected due to reverse lookup failing in our local caching nameserver, the other dns mentioned is one belonging to a hosting provider of ours where we host external websites, so the query currently fails from our local caching server (127.0.0.1) but not on 82.138.243.4 and 82.138.243.24 (our hosting providers dns servers - will attempt to find our from them what they are running might shed some light on things). Jason ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with reverse dns and local caching name server
On Wed, 2009-06-10 at 11:20 +0100, Jason Crummack wrote: > dig @82.138.243.4 30.22.203.in-addr.arpa NS > I get a response from that IP as well, however from mine, I don't, I suspect that's the server cache. Is this IP range still delegated to you? dig 30.22.203.in-addr.arpa NS ; <<>> DiG 9.4.2-P2 <<>> 30.22.203.in-addr.arpa NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14148 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa.IN NS I get a response from that as well, however from mine, I don't, I suspect thats the server cache Is this IP range still delegated to you?/ dig 30.22.203.in-addr.arpa NS ; <<>> DiG 9.4.2-P2 <<>> 30.22.203.in-addr.arpa NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14148 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa.IN NS dig 47.30.22.203.in-addr.arpa @ns01.opensystems.com.au. ; <<>> DiG 9.4.2-P2 <<>> 47.30.22.203.in-addr.arpa @ns01.opensystems.com.au. ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 413 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;47.30.22.203.in-addr.arpa. IN A ;; AUTHORITY SECTION: 30.22.203.in-addr.arpa. 38400 IN SOA ns01.opensystems.com.au. support.opensystems.com.au. 1052091109 10800 3600 604800 38400 Querying your server gets a response, but like mine, none others seem to, what changes have you made recently? a Te$ltra server I query also knows it, but my secondary DNS (located in California) does not either, nor does ns1.exetel so somethings changed ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with reverse dns and local caching name server
Thanks for the reply Noel i still don't understand why that would work on the external name server we have access to and not on our internal one? $ dig @82.138.243.4 30.22.203.in-addr.arpa NS ; <<>> DiG 9.3.2 <<>> @82.138.243.4 30.22.203.in-addr.arpa NS ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16154 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa.IN NS ;; ANSWER SECTION: 30.22.203.in-addr.arpa. 38400 IN NS ns01.opensystems.com.au. 30.22.203.in-addr.arpa. 38400 IN NS ns02.opensystems.com.au. ;; Query time: 1332 msec ;; SERVER: 82.138.243.4#53(82.138.243.4) ;; WHEN: Wed Jun 10 11:18:05 2009 ;; MSG SIZE rcvd: 96 Also didn't understand the 'MyApnic' portion of you comment, the only name server i have access to here is our internal caching one? Jason Noel Butler wrote: Jason, Looks like a DNS delegation error, login to your 'MyApnic' and make sure everything is good. I can not get an external response here ~$ host 203.22.30.47 Host 47.30.22.203.in-addr.arpa not found: 2(SERVFAIL ~$ dig 30.22.203.in-addr.arpa NS ; <<>> DiG 9.4.2-P2 <<>> 30.22.203.in-addr.arpa NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31292 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa. IN NS ;; Query time: 1 msec ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Issue with reverse dns and local caching name server
Jason, Looks like a DNS delegation error, login to your 'MyApnic' and make sure everything is good. I can not get an external response here ~$ host 203.22.30.47 Host 47.30.22.203.in-addr.arpa not found: 2(SERVFAIL ~$ dig 30.22.203.in-addr.arpa NS ; <<>> DiG 9.4.2-P2 <<>> 30.22.203.in-addr.arpa NS ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31292 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;30.22.203.in-addr.arpa.IN NS ;; Query time: 1 msec On Wed, 2009-06-10 at 10:19 +0100, Jason Crummack wrote: > Hi all, > > I'm fairly new to bind configuration and was wondering if you could > point me in the right direction for issues we seem to be having with our > caching name server reverse looking up a particular address, i've been > banging my head against this for the last couple of days now and > wondered if you could point me in the right direction on solving the issue. > > here's what i'm getting with a local host command > > $ host -d 203.22.30.47 127.0.0.1 > > Trying "47.30.22.203.in-addr.arpa" > Received 43 bytes from 127.0.0.1#53 in 0 ms > Trying "47.30.22.203.in-addr.arpa" > Using domain server: > Name: 127.0.0.1 > Address: 127.0.0.1#53 > Aliases: ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Issue with reverse dns and local caching name server
Hi all,
I'm fairly new to bind configuration and was wondering if you could
point me in the right direction for issues we seem to be having with our
caching name server reverse looking up a particular address, i've been
banging my head against this for the last couple of days now and
wondered if you could point me in the right direction on solving the issue.
here's what i'm getting with a local host command
$ host -d 203.22.30.47 127.0.0.1
Trying "47.30.22.203.in-addr.arpa"
Received 43 bytes from 127.0.0.1#53 in 0 ms
Trying "47.30.22.203.in-addr.arpa"
Using domain server:
Name: 127.0.0.1
Address: 127.0.0.1#53
Aliases:
Host 47.30.22.203.in-addr.arpa not found: 2(SERVFAIL)
Received 43 bytes from 127.0.0.1#53 in 0 ms
$ dig +trace @127.0.0.1 -x 203.22.30.47
; <<>> DiG 9.4.3 <<>> +trace @127.0.0.1 -x 203.22.30.47
; (1 server found)
;; global options: printcmd
. 517909 IN NS G.ROOT-SERVERS.NET.
. 517909 IN NS A.ROOT-SERVERS.NET.
. 517909 IN NS B.ROOT-SERVERS.NET.
. 517909 IN NS K.ROOT-SERVERS.NET.
. 517909 IN NS J.ROOT-SERVERS.NET.
. 517909 IN NS M.ROOT-SERVERS.NET.
. 517909 IN NS H.ROOT-SERVERS.NET.
. 517909 IN NS L.ROOT-SERVERS.NET.
. 517909 IN NS C.ROOT-SERVERS.NET.
. 517909 IN NS I.ROOT-SERVERS.NET.
. 517909 IN NS E.ROOT-SERVERS.NET.
. 517909 IN NS F.ROOT-SERVERS.NET.
. 517909 IN NS D.ROOT-SERVERS.NET.
;; Received 492 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms
203.in-addr.arpa. 86400 IN NS TINNIE.ARIN.NET.
203.in-addr.arpa. 86400 IN NS NS-SEC.RIPE.NET.
203.in-addr.arpa. 86400 IN NS NS4.APNIC.NET.
203.in-addr.arpa. 86400 IN NS DNS1.TELSTRA.NET.
203.in-addr.arpa. 86400 IN NS NS1.APNIC.NET.
203.in-addr.arpa. 86400 IN NS NS3.APNIC.NET.
;; Received 185 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 273 ms
30.22.203.in-addr.arpa. 86400 IN NS ns.bigtrolley.com.au.
30.22.203.in-addr.arpa. 86400 IN NS ns.opensystems.com.au.
;; Received 106 bytes from 193.0.0.196#53(NS-SEC.RIPE.NET) in 26 ms
47.30.22.203.in-addr.arpa. 38400 IN PTR mail.opensystems.com.au.
30.22.203.in-addr.arpa. 38400 IN NS ns02.opensystems.com.au.
30.22.203.in-addr.arpa. 38400 IN NS ns01.opensystems.com.au.
;; Received 150 bytes from 203.22.30.26#53(ns.bigtrolley.com.au) in 326 ms
if I use an external dns nameserver available to us the lookup succeeds
$ host -d 203.22.30.47 82.138.243.4
Trying "47.30.22.203.in-addr.arpa"
Using domain server:
Name: 82.138.243.4
Address: 82.138.243.4#53
Aliases:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64989
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;47.30.22.203.in-addr.arpa. IN PTR
;; ANSWER SECTION:
47.30.22.203.in-addr.arpa. 38400 IN PTR mail.opensystems.com.au.
;; AUTHORITY SECTION:
30.22.203.in-addr.arpa. 38400 IN NS ns02.opensystems.com.au.
30.22.203.in-addr.arpa. 38400 IN NS ns01.opensystems.com.au.
Received 118 bytes from 82.138.243.4#53 in 1473 ms
running bind version 9.4.3
named.conf
<<<
options {
directory "/var/named";
query-source address 192.168.0.15 port 53;
allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };
};
logging {
category lame-servers { null; };
};
# main root caches
zone "." {
type hint;
file "root.cache";
};
>>>
Many Thanks
Jason Crummack
Easysoft Limited
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
