problem resolving domains with bind9.5.0-P2
Dear all, we use bind9.5.0-P2 for the internet dns server. Sometimes we get no response for some domains, like this: ; <<>> DiG 9.3.2 <<>> cluster3.eu.messagelabs.com ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34869 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;cluster3.eu.messagelabs.com. IN A ;; Query time: 166 msec ;; SERVER: 195.145.31.131#53(195.145.31.131) ;; WHEN: Fri Aug 21 11:00:01 2009 ;; MSG SIZE rcvd: 45 If we ask the same question a few seconds later, we get a correct answer. ( e.g. two out-of ten we get an error) Then we stop and start the named daemon and it works fine for a while. Any ideas? How can we debug this issue? Thanks in advance. Greets, Matthias ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem resolving domains with bind9.5.0-P2
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34869 While it doesn't help you with your 9.5.0-P2 version, BIND 9.6.1 and newer provide a new query-errors logging category that can be helpful by logging details about various errors. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problem resolving domains with bind9.5.0-P2
Based on the answer size for the query you presented, I'd focus on looking for an upstream filter/device that is blocking answers that are > 512 bytes. On Wed, Sep 9, 2009 at 5:34 AM, Matthias Brehm wrote: > Dear all, > > > > we use bind9.5.0-P2 for the internet dns server. > > Sometimes we get no response for some domains, like this: > > > > ; <<>> DiG 9.3.2 <<>> cluster3.eu.messagelabs.com > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34869 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;cluster3.eu.messagelabs.com. IN A > > > > ;; Query time: 166 msec > > ;; SERVER: 195.145.31.131#53(195.145.31.131) > > ;; WHEN: Fri Aug 21 11:00:01 2009 > > ;; MSG SIZE rcvd: 45 > > > > If we ask the same question a few seconds later, we get a correct answer. ( > e.g. two out-of ten we get an error) > > Then we stop and start the named daemon and it works fine for a while. > > > > Any ideas? > > How can we debug this issue? > > > > Thanks in advance. > > > > Greets, Matthias > > > > > > > > ___ > 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
Re: root and in-addr.arpa zone transfers
Michael,
Here's a snippet from my named.conf which does what you're talking
about. I use this in our recursive resolvers, but for authoritative
servers, I find the hints file to be somewhat more robust.
FYI, I stole this originally from the default FreeBSD named.conf file
that got pushed out with a 6.something update. There was some
controversy in the FreeBSD mailing lists about it, so I have no idea
whether it's still used or not.
zone "." {
type slave;
file "slave/root.slave";
masters {
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4; // G.ROOT-SERVERS.NET.
193.0.14.129; // K.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "slave/arpa.slave";
masters {
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4; // G.ROOT-SERVERS.NET.
193.0.14.129; // K.ROOT-SERVERS.NET.
};
notify no;
};
zone "in-addr.arpa" {
type slave;
file "slave/in-addr.arpa.slave";
masters {
192.33.4.12;// C.ROOT-SERVERS.NET.
192.112.36.4; // G.ROOT-SERVERS.NET.
193.0.14.129; // K.ROOT-SERVERS.NET.
};
notify no;
};
Rich Goodson
Sr. Unix Administrator
Mediacom Communications
On Sep 9, 2009, at 1:23 AM, Michael Monnerie wrote:
Hello,
right now I'm using scripts to download root.zone and in-addr.arpa
from
internic.net. But this is a non-standard way, I'd prefer to directly
slave and zone-transfer those 2 zones.
Is it possible, and can you show the bind config for these?
Thanks a lot,
mfg zmi
--
// Michael Monnerie, Ing.BSc- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
___
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
Re: root and in-addr.arpa zone transfers
On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson wrote:
> zone "." {
> type slave;
> file "slave/root.slave";
> masters {
> 192.33.4.12; // C.ROOT-SERVERS.NET.
> 192.112.36.4; // G.ROOT-SERVERS.NET.
> 193.0.14.129; // K.ROOT-SERVERS.NET.
> };
> notify no;
> };
Interestingcan any of the root servers be used, or must it be just
these three?
--
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
one DNS names to multiple IP Addresses(Round Robin DNS)
Hi Anybody can help to explain the side effect of configuring the DNS name to multiple IP addresses(Round Robin DNS). Thanks & Regards Nagaraj ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: one DNS names to multiple IP Addresses(Round Robin DNS)
In article , Balanagaraju Munukutla <9ba...@sg.ibm.com> wrote: > Hi > > Anybody can help to explain the side effect of configuring the DNS name to > multiple IP addresses(Round Robin DNS). If you're planning to use it for load sharing, then the effect is very basic - requests get shared equally among the addresses irrespective of load on the target system or whether the system is offering the service or not. If one of the target systems goes down then clients which are directed to that system will either get rejected or time out, depending on the type of failure. You can mitigate this by using watchdog scripts, short TTLs and dynamic DNS updates. In short it's cheap and cheerful load balancing. A large commercial organisation might not want to rely on it, but depending on the application it can work well enough. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
9.2.2 vs 9.5.1
I'm using 3 dns servers with Bind bind-9.2.2.P3-9
Master A (domain1 + domain2)
Slave B (domain1)
Slave C (domain2)
Now I'm migrating master A to Bind 9.5.1.dfsg.P3-1 together OS (Debian
Lenny) so I'm interesting to know if there is some incompatible settings
from/to slave servers.
For example in slave B,C there is no setting about "auth-nxdomain directive"
while in server A I found set "auth-nxdomain no"; I have to specify in
server A these 2 options to permit only zones transfer to these only 2
servers ?
allow-transfer { IpServerB }
allow-transfer { IpServerC }
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.2.2 vs 9.5.1
Riccardo Castellani wrote:
I'm using 3 dns servers with Bind bind-9.2.2.P3-9
Master A (domain1 + domain2)
Slave B (domain1)
Slave C (domain2)
Now I'm migrating master A to Bind 9.5.1.dfsg.P3-1 together OS (Debian
Lenny) so I'm interesting to know if there is some incompatible
settings from/to slave servers.
For example in slave B,C there is no setting about "auth-nxdomain
directive" while in server A I found set "auth-nxdomain no";
According to the ARM, no change from 9.2.x to 9.5.x. The default is
still "no", so "auth-nxdomain no" is technically redundant. Some folks
like to make everything explicit, while others like to keep their
configs as minimal as possible and therefore go with default settings
wherever possible; it's a matter of personal preference.
I have to specify in server A these 2 options to permit only zones
transfer to these only 2 servers ?
allow-transfer { IpServerB }
allow-transfer { IpServerC }
According to the ARM, no change from 9.2.x to 9.5.x. The default is
still to allow all zone transfers. Note that if you use TSIG keys for
authenticating zone transfers, you can re-address your slaves at will
without having to keep your allow-transfer clauses up to date to match.
Generally speaking, key-based security is stronger than
source-address-based security anyway.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.6.1-P1 ignoring listen-on directive
Hi,
I'm testing Bind 9.6.1-P1 on Solaris 10 SPARC (64bit/Sun Studio 12.1) &
I noticed this in the logs:
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface lo0, 127.0.0.1#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0, 153.104.92.2#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0:1, 153.104.92.4#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge1, 10.104.36.20#53
I only wanted named to listen on one interface + the loopback, so I
added a listen-on statement in named.conf:
acl testnets { 153.104.244.0/24; 153.104.248.0/24; };
options {
directory "/opt/isc/bind/var/db";
allow-query { testnets; };
listen-on { localhost; 153.104.92.2; };
listen-on-v6 { none; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
notify no;
};
But, I still have the same log entries when I start named. I then
modified named.conf to specifically exclude the other interfaces:
listen-on { localhost; 153.104.92.2; !153.104.92.4; !10.104.36.20; };
But, again, I'm still seeing it state that it is listening on the
excluded interfaces. I tried increasing the debug level, but I didn't
see any additional info pertaining to this. I know that it is listening
on the excluded interfaces because I see a queries on the 10.104.36.20
interface:
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1041: query (cache) 'ATF/A/IN' denied
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1046: query (cache) 'ATP.villanova.edu/A/IN' denied
Is this a known problem? It's an issue for us because we restrict DNS
queries to particular interfaces. If it isn't a known bug, I'd be glad
to help troubleshoot this problem.
Thanks.
-John
--
John Center
Villanova University
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1-P1 ignoring listen-on directive
Of course, right after hitting enter on this message, I came across a
message from last year about localhost mapping to all interfaces, not
just 127.0.0.1. I created a "loopback" acl & used it instead that
worked. Sorry for the noise.
-John
On 09/09/2009 03:04 PM, John Center wrote:
Hi,
I'm testing Bind 9.6.1-P1 on Solaris 10 SPARC (64bit/Sun Studio 12.1)&
I noticed this in the logs:
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface lo0, 127.0.0.1#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0, 153.104.92.2#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0:1, 153.104.92.4#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge1, 10.104.36.20#53
I only wanted named to listen on one interface + the loopback, so I
added a listen-on statement in named.conf:
acl testnets { 153.104.244.0/24; 153.104.248.0/24; };
options {
directory "/opt/isc/bind/var/db";
allow-query { testnets; };
listen-on { localhost; 153.104.92.2; };
listen-on-v6 { none; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
notify no;
};
But, I still have the same log entries when I start named. I then
modified named.conf to specifically exclude the other interfaces:
listen-on { localhost; 153.104.92.2; !153.104.92.4; !10.104.36.20; };
But, again, I'm still seeing it state that it is listening on the
excluded interfaces. I tried increasing the debug level, but I didn't
see any additional info pertaining to this. I know that it is listening
on the excluded interfaces because I see a queries on the 10.104.36.20
interface:
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1041: query (cache) 'ATF/A/IN' denied
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1046: query (cache) 'ATP.villanova.edu/A/IN' denied
Is this a known problem? It's an issue for us because we restrict DNS
queries to particular interfaces. If it isn't a known bug, I'd be glad
to help troubleshoot this problem.
Thanks.
-John
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.6.1-P1 ignoring listen-on directive
Syntax. The parser is matching on "localhost" before it sees the negated
elements.
- Kevin
John Center wrote:
Hi,
I'm testing Bind 9.6.1-P1 on Solaris 10 SPARC (64bit/Sun Studio 12.1)
& I noticed this in the logs:
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface lo0, 127.0.0.1#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0, 153.104.92.2#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge0:1, 153.104.92.4#53
Sep 9 13:15:31 ns3a/ns3a named[23042]: [ID 873579 daemon.info]
listening on IPv4 interface bge1, 10.104.36.20#53
I only wanted named to listen on one interface + the loopback, so I
added a listen-on statement in named.conf:
acl testnets { 153.104.244.0/24; 153.104.248.0/24; };
options {
directory "/opt/isc/bind/var/db";
allow-query { testnets; };
listen-on { localhost; 153.104.92.2; };
listen-on-v6 { none; };
};
zone "0.0.127.in-addr.arpa" in {
type master;
file "db.127.0.0";
notify no;
};
But, I still have the same log entries when I start named. I then
modified named.conf to specifically exclude the other interfaces:
listen-on { localhost; 153.104.92.2; !153.104.92.4; !10.104.36.20; };
But, again, I'm still seeing it state that it is listening on the
excluded interfaces. I tried increasing the debug level, but I didn't
see any additional info pertaining to this. I know that it is
listening on the excluded interfaces because I see a queries on the
10.104.36.20 interface:
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1041: query (cache) 'ATF/A/IN' denied
Sep 9 13:09:16 ns3a/ns3a named[22867]: [ID 873579 daemon.info] client
10.104.109.0#1046: query (cache) 'ATP.villanova.edu/A/IN' denied
Is this a known problem? It's an issue for us because we restrict DNS
queries to particular interfaces. If it isn't a known bug, I'd be glad
to help troubleshoot this problem.
Thanks.
-John
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
salting NSEC3
Hello, I'm trying to better understand NSEC3. I have a signed zone for which I periodically resign expiring RRs with expiring RRSIGs using dnssec-signzone. When I do so, I use a different salt each time, which results in multiple salts being used in the zone. According to RFC 5155: This is harmless, since each RR stands alone (that is, it denies the set of owner names whose hashes, using the salt in the NSEC3 RR, fall between the two hashes in the NSEC3 RR) -- it is only the server that needs a complete set of NSEC3 RRs with the same salt in order to be able to answer every possible query. Also, according to RFC 5155: There MUST be at least one complete set of NSEC3 RRs for the zone using the same salt value. and: If an NSEC3PARAM RR is present at the apex of a zone with a Flags field value of zero, then there MUST be an NSEC3 RR using the same hash algorithm, iterations, and salt parameters present at every hashed owner name in the zone. That is, the zone MUST contain a complete set of NSEC3 RRs with the same hash algorithm, iterations, and salt parameters. So from what I gather, each time a new salt (and therefore NSEC3PARAM) is introduced to the mix, a new NSEC3 chain is generated, so given n distinct owner names in the zone, there are n*(num NSEC3PARAM RRs) NSEC3 RRs and covering RRSIGs. I'm looking for a sanity check here. Aside from the increase in zone size, there shouldn't be any resolution/validation problems with this, correct? Is it more reasonable to use the same salt until the zone is completely (i.e., all RRs) resigned? Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root and in-addr.arpa zone transfers
On 09.09.09 11:00, Rick Dicaire wrote:
> On Wed, Sep 9, 2009 at 10:51 AM, Rich Goodson
> wrote:
> > zone "." {
> > type slave;
> > file "slave/root.slave";
> > masters {
> > 192.33.4.12; // C.ROOT-SERVERS.NET.
> > 192.112.36.4; // G.ROOT-SERVERS.NET.
> > 193.0.14.129; // K.ROOT-SERVERS.NET.
> > };
> > notify no;
> > };
>
> Interestingcan any of the root servers be used, or must it be just
> these three?
you can try dig axfr from all of them but many of them don't allow
transfers. I guess he already did it and above is list of servers that do
allow transfers...
--
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.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: one DNS names to multiple IP Addresses(Round Robin DNS)
On Wed, Sep 09, 2009 at 05:47:34PM +0100, Sam Wilson wrote: > In article , > Balanagaraju Munukutla <9ba...@sg.ibm.com> wrote: > > Hi > > > > Anybody can help to explain the side effect of configuring the DNS name to > > multiple IP addresses(Round Robin DNS). > > If you're planning to use it for load sharing, then the effect is very > basic - requests get shared equally among the addresses irrespective of > load on the target system or whether the system is offering the service > or not. If one of the target systems goes down then clients which are > directed to that system will either get rejected or time out, depending > on the type of failure. You can mitigate this by using watchdog > scripts, short TTLs and dynamic DNS updates. > > In short it's cheap and cheerful load balancing. A large commercial > organisation might not want to rely on it, but depending on the > application it can work well enough. There are several problems with using this for load balancing. The first is, simply, it will not work unless the name server that is authoritative for this zone is also your resolving name server. If there are ANY resolving name servers between the user and the authoritative name server - as there usually is/are - then it's the "round robin" policy - or lack thereof - of the last caching name server before your stub resolver that will dictate how the addresses are delivered. Second, if one of the system goes down, then its IP address is still in the rotation, again, unless some clever dynamic-DNS insertion and deletion strategy is used. This means that users will get frustrated when their Web browser sometimes gets the Web site and sometimes doesn't; or some automatic process that is trying to get your information will not fail cleanly. ISTM, it's better to try and do failover some other way, such as with high-availability Linux, than to try to get DNS to do load balancing. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
