Re: Anyway to disable dns_zone_nscheck in 9.8.0?
In message BANLkTi=h1onrtxdtdfmpgkz7slrglyt...@mail.gmail.com, Rodney Hives w rites: The dns_zone_nscheck is a real pain for domains that do not have valid A records (for their NS records). Is there anyway to disable this check? I started noticing this problem in 9.7xs. But at this point I just want to remove it as it is causing many problems for previous configured name servers. There seems to value in the master.h for DNS_MASTER_CHECKNS which is similar to the other checks (DNS_MASTER_CHECKMX, DNS_MASTER_CHECKMXFAIL, etc.) that you can turn off in the options of named.conf. But I do not see any option to remove the dns_zone_nscheck. Has anyone removed this function safely? If so, how? Thank you! -Rodney Hives Please explain the operating conditions under which when you think this is a sensible thing to do? A nameserver without address records is pointless. A nameserver pointing to a CNAME/DNAME causes resolution problems. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Resolver issue - drop in qps and memory leak
Hi all, We are running a couple of resolvers using BIND 9.6.2-p2 on FreeBSD 7.1 and are peaking at 10,000 queries per second (qps). Recently, the qps on one resolver dropped dramatically to 3000 during the peak period. The secondary picked up the additional queries and we had a few complaints about response times, but not much more than that. Restarting named seems to have resolved it and we are back at 10,000 qps during peak - for now. We also observed the following during the problem period: - memory usage increased steadily from 10% to 15% (typically it remains steady at 10%) - many events in the general log like this: general: info: sockmgr 0x800d46000: maximum number of FD events (64) received Appreciate any help to determine the root cause. Regards, Dennis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS queries with 3 networks
hello floks, i have a DNS server running bind-9.7.3 on a linux box, 3 differents networks connected to 3 ethernet cards: eth0: 192.168.1.1/24 eth1: 172.16.1.1/24 eth2: 10.140.27.1/24 i would like to have the same DNS resolving the good address from the good network, example: from the 192.168.1.1/24 network:host mydns.example.com = 192.168.1.10 from the 172.16.1.1/24 network: host mydns.example.com = 172.16.1.10 from the 10.140.27.1/24 network:host mydns.example.com = 10.140.27.10 but actually my problem is that if i run ` host mydns.example.com` from any network the answer is similar to: from eth0 network (192.168.1.1/24) $ host mydns.example.com mydns.example.com has address 10.140.27.10 mydns.example.com has address 192.168.1.10 mydns.example.com has address 172.16.1.10 how to resolve this ? i would like to have the same results but in the order that i can ping the server with i's hostname: from eth0 network (192.168.1.1/24) $ host mydns.example.com mydns.example.com has address 192.168.1.10 mydns.example.com has address 10.140.27.10 mydns.example.com has address 172.16.1.10 or from eth1 network (172.16.1.1/24) $ host mydns.example.com mydns.example.com has address 172.16.1.10 mydns.example.com has address 192.168.1.10 mydns.example.com has address 10.140.27.10 and from eth2 network (10.140.27.1/24) $ host mydns.example.com mydns.example.com has address 10.140.27.10 mydns.example.com has address 172.16.1.10 mydns.example.com has address 192.168.1.10 thank you very much Banana ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS queries with 3 networks
On 08.04.11 09:11, Flex Banana wrote: how to resolve this ? i would like to have the same results but in the order that i can ping the server with i's hostname: from eth0 network (192.168.1.1/24) $ host mydns.example.com mydns.example.com has address 192.168.1.10 mydns.example.com has address 10.140.27.10 mydns.example.com has address 172.16.1.10 or from eth1 network (172.16.1.1/24) $ host mydns.example.com mydns.example.com has address 172.16.1.10 mydns.example.com has address 192.168.1.10 mydns.example.com has address 10.140.27.10 and from eth2 network (10.140.27.1/24) $ host mydns.example.com mydns.example.com has address 10.140.27.10 mydns.example.com has address 172.16.1.10 mydns.example.com has address 192.168.1.10 look at sortlist statement in bind's config. -- 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. I drive way too fast to worry about cholesterol. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS queries with 3 networks
Dnia 2011-04-08 09:11 Flex Banana napisał(a): hello floks, i have a DNS server running bind-9.7.3 on a linux box, 3 differents networks connected to 3 ethernet cards: eth0: 192.168.1.1/24 eth1: 172.16.1.1/24 eth2: 10.140.27.1/24 i would like to have the same DNS resolving the good address from the good network, example: from the 192.168.1.1/24 network: host mydns.example.com = 192.168.1.10 from the 172.16.1.1/24 network:host mydns.example.com = 172.16.1.10 from the 10.140.27.1/24 network: host mydns.example.com = 10.140.27.10 The only way would be to create 3 different zone files, with those addresses, and 3 different views on this sever, each having a different zone file and configured for different networks I don't have bind ARM on-hand, but there was a section on views. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
A beginners question regarding a caching-only name server
I am new to using BIND and thought that I would start by setting up a
caching-only name server on a VM running CentOS 5.5. While in this
mode, my understanding is that named should be passively listening for
any DNS requests that are resolved and be adding them to its local DB.
Adding localhost to /etc/resolv.conf shouldn't be necessary in order for
entries to be added to the DB but obviously required if you want to make
use of the DNS caching.
What I'm observing is that any DNS requests that are resolved aren't
being added to the DB - i.e. the result of rndc dumpdb is always
empty. My named.conf file is as posted inline below; this is a vanilla
named.caching-nameserver.conf (as packaged by CentOS) aside from my
adding the VMWare subnet 192.168.239.0/24 which my VM is on. I also
post the output of named -g along with named.local below.
Any assistance would be appreciated.
named -g
[root@localhost named]# named -g
08-Apr-2011 21:11:39.672 starting BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 -g
08-Apr-2011 21:11:39.673 found 1 CPU, using 1 worker thread
08-Apr-2011 21:11:39.673 using up to 4096 sockets
08-Apr-2011 21:11:39.679 loading configuration from '/etc/named.conf'
08-Apr-2011 21:11:39.680 max open files (1024) is smaller than max
sockets (4096)
08-Apr-2011 21:11:39.681 using default UDP/IPv4 port range: [1024, 65535]
08-Apr-2011 21:11:39.682 using default UDP/IPv6 port range: [1024, 65535]
08-Apr-2011 21:11:39.684 listening on IPv4 interface lo, 127.0.0.1#53
08-Apr-2011 21:11:39.684 listening on IPv4 interface eth0,
192.168.239.141#53
08-Apr-2011 21:11:39.686 /etc/named.conf:24: using specific query-source
port suppresses port randomization and can be insecure.
08-Apr-2011 21:11:39.686 /etc/named.conf:25: using specific query-source
port suppresses port randomization and can be insecure.
08-Apr-2011 21:11:39.687 command channel listening on 127.0.0.1#953
08-Apr-2011 21:11:39.687 command channel listening on ::1#953
08-Apr-2011 21:11:39.687 ignoring config file logging statement due to
-g option
08-Apr-2011 21:11:39.689 zone 0.in-addr.arpa/IN/localhost_resolver:
loaded serial 42
08-Apr-2011 21:11:39.689 zone
0.0.127.in-addr.arpa/IN/localhost_resolver: loaded serial 1997022700
08-Apr-2011 21:11:39.690 zone 255.in-addr.arpa/IN/localhost_resolver:
loaded serial 42
08-Apr-2011 21:11:39.690 zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/localhost_resolver:
loaded serial 1997022700
08-Apr-2011 21:11:39.690 zone localdomain/IN/localhost_resolver: loaded
serial 42
08-Apr-2011 21:11:39.691 zone localhost/IN/localhost_resolver: loaded
serial 42
08-Apr-2011 21:11:39.691 running -- I perform successful DNS
queries on the box at this point
08-Apr-2011 21:12:05.091 dumpdb started
08-Apr-2011 21:12:05.092 dumpdb complete -- db is always empty
# rndc dumpdb
# - no output
named.conf
--
options {
listen-on port 53 { 127.0.0.1; 192.168.239.0/24; };
//listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
// Those options should be used carefully because they
// disable port randomization
query-sourceport 53;
query-source-v6 port 53;
allow-query { localhost; 192.168.239.0/24; };
allow-query-cache { localhost; 192.168.239.0/24; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; 192.168.239.0/24;};
match-destinations { localhost; 192.168.239.0/24;};
recursion yes;
include /etc/named.rfc1912.zones;
};
named.local
---
$TTL86400
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
360; Expire
86400 ); Minimum
IN NS localhost.
1 IN PTR localhost.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
Patrick Rynhart p.rynh...@massey.ac.nz wrote: I am new to using BIND and thought that I would start by setting up a caching-only name server on a VM running CentOS 5.5. While in this mode, my understanding is that named should be passively listening for any DNS requests that are resolved and be adding them to its local DB. Adding localhost to /etc/resolv.conf shouldn't be necessary in order for entries to be added to the DB but obviously required if you want to make use of the DNS caching. No, only DNS requests that are handled by the server itself are cached. There is no sniffing going on. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Fair Isle, Faeroes, South-east Iceland: Westerly 6 to gale 8, occasionally severe gale 9 in Fair Isle and Faeroes, backing southerly 4 or 5. Rough or very rough, occasionally high at first. Rain or showers. Moderate or good, occasionally poor. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
On 8/04/2011 10:11 p.m., Tony Finch wrote:
No, only DNS requests that are handled by the server itself are cached.
There is no sniffing going on.
Tony.
Thank you for the clarification. If I add nameserver 127.0.0.1 to the
VM (and comment out the existing name servers) and attempt to resolve a
DNS entry, the I see output similar to the following:
08-Apr-2011 22:51:50.116 network unreachable resolving
'www.redhat.com/A/IN': 2001:500:2f::f#53
08-Apr-2011 22:51:54.023 network unreachable resolving
'www.redhat.com/A/IN': 2001:503:c27::2:30#53
08-Apr-2011 22:51:54.024 network unreachable resolving './NS/IN':
2001:503:c27::2:30#53
I understand that this is because there is no upstream DNS for BIND as
configured in my named.conf. However, if I try to add a forward
forwarders {
192.168.239.2;
};
(where the host 192.168.239.2 is upstream DNS in my case), then DNS
queries are resolved by the client but do not appear to be cached, i.e.:
# rndc dumpdb
#
What am I missing ? Is it not possible to use a forwarders directive
in combination with a name caching server ?
Thanks,
Patrick
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
Dnia 2011-04-08 21:58 Patrick Rynhart napisał(a):
I am new to using BIND and thought that I would start by setting up a
caching-only name server on a VM running CentOS 5.5. While in this
mode, my understanding is that named should be passively listening for
any DNS requests that are resolved and be adding them to its local DB.
Adding localhost to /etc/resolv.conf shouldn't be necessary in order for
entries to be added to the DB but obviously required if you want to make
use of the DNS caching.
What I'm observing is that any DNS requests that are resolved aren't
being added to the DB - i.e. the result of rndc dumpdb is always
empty. My named.conf file is as posted inline below; this is a vanilla
named.caching-nameserver.conf (as packaged by CentOS) aside from my
adding the VMWare subnet 192.168.239.0/24 which my VM is on. I also
post the output of named -g along with named.local below.
You say you successfully perform queries on that box. How are you doing
this?
dig something @localhost
dig something
ping something
Last two might not work, as it asks resolver for that box, which is
configured in resolv.conf and might not be localhost
The first is guaranteed to ask this bind.
Also, see below for remarks on your configuration.
named.conf
--
options {
listen-on port 53 { 127.0.0.1; 192.168.239.0/24; };
192.168.239.0 should be a single address, not a range. It's address bind
listens on, not the one it can receive queries from.
//listen-on-v6 port 53 { ::1; };
directory /var/named;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file /var/named/data/named_mem_stats.txt;
// Those options should be used carefully because they
// disable port randomization
query-sourceport 53;
query-source-v6 port 53;
allow-query { localhost; 192.168.239.0/24; };
allow-query-cache { localhost; 192.168.239.0/24; };
};
logging {
channel default_debug {
file data/named.run;
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; 192.168.239.0/24;};
match-destinations { localhost; 192.168.239.0/24;};
recursion yes;
include /etc/named.rfc1912.zones;
};
You are sure you need view? This one here doesn't seem to add anything , and
it does seem strange.
You specify here, that clients from your local IP subnet, that ask for names
in your local IP subnet can ask recursive queries, and have some pretty
standard zones.
My quess would be that it won't require recursive queries. And if you want
to limit who can use your server recursively,
its better to use option {allow-recursion{ 192.168.239.0/24;};}
Regards,
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Resolver issue - drop in qps and memory leak
Hi Dennis, There are some fixes for cache management issues on recursive servers that have been released recently. This sounds like it might have been one of those problems. If you want to stay on 9.6, then I'd recommend 9.6-ESV-R4 to you Otherwise you might like to take a look at 9.7.3. Cathy On 08/04/11 07:41, Dennis Perisa wrote: Hi all, We are running a couple of resolvers using BIND 9.6.2-p2 on FreeBSD 7.1 and are peaking at 10,000 queries per second (qps). Recently, the qps on one resolver dropped dramatically to 3000 during the peak period. The secondary picked up the additional queries and we had a few complaints about response times, but not much more than that. Restarting named seems to have resolved it and we are back at 10,000 qps during peak - for now. We also observed the following during the problem period: - memory usage increased steadily from 10% to 15% (typically it remains steady at 10%) - many events in the general log like this: general: info: sockmgr 0x800d46000: maximum number of FD events (64) received Appreciate any help to determine the root cause. Regards, Dennis ___ 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: A beginners question regarding a caching-only name server
Dnia 2011-04-08 23:00 Patrick Rynhart napisał(a): On 8/04/2011 10:11 p.m., Tony Finch wrote: No, only DNS requests that are handled by the server itself are cached. There is no sniffing going on. Tony. Thank you for the clarification. If I add nameserver 127.0.0.1 to the VM (and comment out the existing name servers) and attempt to resolve a DNS entry, the I see output similar to the following: 08-Apr-2011 22:51:50.116 network unreachable resolving 'www.redhat.com/A/IN': 2001:500:2f::f#53 08-Apr-2011 22:51:54.023 network unreachable resolving 'www.redhat.com/A/IN': 2001:503:c27::2:30#53 08-Apr-2011 22:51:54.024 network unreachable resolving './NS/IN': 2001:503:c27::2:30#53 I understand that this is because there is no upstream DNS for BIND as configured in my named.conf. However, if I try to add a forward It might be, but it also might be because you have no IPv6 connectivity. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyway to disable dns_zone_nscheck in 9.8.0?
Can you explain why you need that? When you have hundreds / thousands of existing zones (from shared hosting) from users it is sometimes impossible to go in a fix all of the mistakes. Right now these zones work (queries are answered in 9.6) but the domains are not even loaded when trying to upgrade. It would be nice to just have a warning and still serve the queries instead of a you are offline decision (since the zone does not load now). It wouldn't be too hard to add a zone configuration option to disable this check (it would set the DNS_ZONEOPT_NOCHECKNS flag in the zone options before loading the masterfile). But I'm confused why one would want to serve a zone if it isn't going to work anyway. The zone does work. The www records work, the mail records work. The NS records even work. The problem is that they are missing some A records. The truth is that they usually have the appropriate A records setup at the registrar (comes back as glue) so everything works anyway. They are just missing the corresponding A records in their zone. No reason to take the zone completely offline when doing an upgrade. Just my opinion would be extremely helpful when doing upgrades on BIND for existing users. -- Best regards, -Rodney Hives (Internet user since... well before Gore built it) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyway to disable dns_zone_nscheck in 9.8.0?
On Fri, Apr 8, 2011 at 1:49 AM, Mark Andrews ma...@isc.org wrote: Please explain the operating conditions under which when you think this is a sensible thing to do? A nameserver without address records is pointless. A nameserver pointing to a CNAME/DNAME causes resolution problems. Here is an example that works in BIND 9.6x: $ORIGIN . $TTL 86400 ; 1 day mydomain.com.au IN SOA ns0.mydomain.com.au. admin.mydomain.com.au. ( 2011010104 ; serial 43200 ; refresh (12 hours) 7200; retry (2 hours) 1209600 ; expire (2 weeks) 1800; minimum (30 minutes) ) $TTL 1800 ; 30 minutes NS ns0.mydomain.com.au. NS ns1.mydomain.com.au. NS ns2.mydomain.com.au. A 1.1.1.1 MX 10 mail.mydomain.com.au. $ORIGIN mydomain.com.au. ftp A 1.1.1.1 mailA 2.2.2.2 pop CNAME mail smtpCNAME mail ssh A 1.1.1.1 www CNAME mydomain.com.au. Is this domain 100% valid?... no... but it still works. The A records for the name servers are actually still resolving since the regsitrar will return them in glue. But understandably... this domain is not 100% valid. But to force the domain offline is just preventing many shared hosting environments to move to newer versions of BIND (or switch off of BIND since they do not understand the problem). Give a warning... that is fine... But to prevent the domain from loading is just too harsh and an immediate drastic measure during an upgrade. It would be nice if it was a configuration option just like all of the other checks. This same function seems also to be called in update.c.. also causing problems. I would just like this function to never be called but I have not been able to determine if it does other things necessary. -- Best regards, -Rodney Hives (Internet user since... well before Gore built it) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: A beginners question regarding a caching-only name server
On 8 April 2011 12:00, Patrick Rynhart p.rynh...@massey.ac.nz wrote: (where the host 192.168.239.2 is upstream DNS in my case), then DNS queries are resolved by the client but do not appear to be cached, i.e.: # rndc dumpdb # What am I missing ? Remember that rndc dumpdb doesn't actually dump the cache to stdout. Has it actually written to named_dump.db in named's working directory? Regards, Andrew ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
programmatically determining whether any zones frozen?
greetings, is there a way to programmatically determine if there are any zones frozen? if so, any way to determine the specific zone(s)? what i'm wanting to do is write a monitoring script to sound an alert if there are any zones that have been frozen for more then x minutes. rndc doesn't provide that info and i haven't found anything else to accomplish the task. thanks for the help. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bogus Wild Card DNS
I am trying to set up bind9.7.2P3 in a special manner such as is used in network registration setups in which named always returns the address of a registration server except for a few other domains that supply updates and antivirus scans, etc. In this case, I have microsoft.com as the one allowed domain and everything else should return the wild card A record. What is happening right now is that the one special allowed domain works fine and all else returned a SERVFAIL rather than resolving to what will eventually be the registration server. The microsoft allowed zone is defined in named.conf with forwarders My understanding is that the only real zone one needs is the hint zone or . and here is mine: @ IN NS netreg.it.okstate.edu. microsoft.com. IN NS netreg.it.okstate.edu. * IN A 139.78.6.193 Why am I not getting resolution to 139.78.6.193 for any other query? The log isn't complaining about much of anything but any query that is not microsoft returns that SERVFAIL message. I must remind anybody experimenting with something like this to be sure to put a bogus DNS clause in your functional production DNS's so that anything that might somehow leak out of this experiment is treated as junk and ignored. Many thanks. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyway to disable dns_zone_nscheck in 9.8.0?
In message banlktimic+ndbnj_rovnhqwzas130bv...@mail.gmail.com, Rodney Hives w rites: On Fri, Apr 8, 2011 at 1:49 AM, Mark Andrews ma...@isc.org wrote: Please explain the operating conditions under which when you think this is a sensible thing to do? A nameserver without address records is pointless. A nameserver pointing to a CNAME/DNAME causes resolution problems. Here is an example that works in BIND 9.6x: $ORIGIN . $TTL 86400 ; 1 day mydomain.com.au IN SOA ns0.mydomain.com.au. admin.mydomain.com.au. ( 2011010104 ; serial 43200 ; refresh (12 hours) 7200; retry (2 hours) 1209600 ; expire (2 weeks) 1800; minimum (30 minutes) ) $TTL 1800 ; 30 minutes NS ns0.mydomain.com.au. NS ns1.mydomain.com.au. NS ns2.mydomain.com.au. A 1.1.1.1 MX 10 mail.mydomain.com.au. $ORIGIN mydomain.com.au. ftp A 1.1.1.1 mailA 2.2.2.2 pop CNAME mail smtpCNAME mail ssh A 1.1.1.1 www CNAME mydomain.com.au. Is this domain 100% valid?... no... but it still works. The A records for the name servers are actually still resolving since the regsitrar will return them in glue. Do you realise how increadibly fragile that configuration is? The moment the recursive server asks for the addresses of the nameservers it will fall over. Yes the recursive nameserver can get into a state where it will make that request as part of resolving some other name in the zone. You don't need a external query for the nameserver names. But understandably... this domain is not 100% valid. But to force the domain offline is just preventing many shared hosting environments to move to newer versions of BIND (or switch off of BIND since they do not understand the problem). Nobody is preventing you fixing the zones. Give a warning... that is fine... But to prevent the domain from loading is just too harsh and an immediate drastic measure during an upgrade. It would be nice if it was a configuration option just like all of the other checks. People ignore warnings. We have 2 decades of experience of people ignoring warnings. The code was put in because we were sick and tired of having to contact people with misconfigured zones like this that were causing resolution failures. We made it a warning initially. It was made a fatal error a couple of releases later. The version you upgraded from warned about this. BIND 9.4 warned about this. named-checkzone from BIND 9.4 produces the following on your zone. It calls exactly the same code named uses. zone mydomain.com.au/IN: NS 'ns0.mydomain.com.au' has no address records (A or ) zone mydomain.com.au/IN: NS 'ns1.mydomain.com.au' has no address records (A or ) zone mydomain.com.au/IN: NS 'ns2.mydomain.com.au' has no address records (A or ) zone mydomain.com.au/IN: loaded serial 2011010104 OK Your logs would have been full of complaints. You could have run named-checkconf -z and seen all the errors before you started named. This same function seems also to be called in update.c.. also causing problems. I would just like this function to never be called but I have not been able to determine if it does other things necessary. It prevents the zone getting into a state where it won't load on a restart from this test. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND9 fails resolving after connecting to VPN
Hello, [first sorry please my English] I have installed Bind9 on Ubuntu 10.10 - just for personal use (no zones, ...). I did not have any problems until I now try to use some free VPN services based on PPTP or OpenVPN. After connect to them (new network device created - tun or tap and default route changes) my BIND is not able to reach other (root) nameservers. And resolve requests fails. Restarting of BIND service do not help. These VPN services do not offer own DNS servers and do not change /etc/resolv.conf. If I change my resolf.conf to e.g ISPs DNS server, I can then normally surf on web, ... == VPN works ok, routes are ok too. After shutting down the VPN, my BIND then works normally again. In attachment are ip routes before and after up of VPN and logs of VPN itself and log of my BIND. PLEASE HELP me to get working my BIND also when VPN connection is active. My knowlidge about BIND config is minimal and I have no Idea, why all apps can communicate over the new route (over the VPN) and BIND fails and logs: network unreachable. If I see on the BIND log, is not tho problem with IPv6 (which I do not use (and understand))? Thanks --kapetr ** before VPN 10.6.6.0/24 dev eth0 proto kernel scope link src 10.6.6.10 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default via 10.6.6.138 dev eth0 proto static root@duron650:/etc/bind# ** after VPN comes up root@duron650:/etc/bind# ip route list 173.203.198.31 via 10.6.6.138 dev eth0 proto static 204.232.203.12 via 10.6.6.138 dev eth0 src 10.6.6.10 204.232.203.12 dev ppp0 proto kernel scope link src 192.168.10.41 10.6.6.0/24 dev eth0 proto kernel scope link src 10.6.6.10 metric 1 169.254.0.0/16 dev eth0 scope link metric 1000 default dev ppp0 proto static root@duron650:/etc/bind# root@duron650:/etc/bind# ifconfig eth0 Link encap:Ethernet HWadr 00:11:d8:10:57:6e inet adr:10.6.6.10 VÅ¡esmÄr:10.6.6.255 Maska:255.255.255.0 inet6-adr: fe80::211:d8ff:fe10:576e/64 Rozsah:Linka AKTIVOVÃNO VÅ ESMÄROVÃ_VYSÃLÃNà BÄŽà MULTICAST MTU:1500 Metrika:1 RX packets:45850 errors:0 dropped:0 overruns:0 frame:0 TX packets:47074 errors:0 dropped:0 overruns:0 carrier:0 kolizÃ:0 délka odchozà fronty:1000 PÅijato bajtů: 21574817 (21.5 MB) Odesláno bajtů: 10146684 (10.1 MB) PÅeruÅ¡enÃ:23 VstupnÄ/Výstupnà port:0xc000 loLink encap:MÃstnà smyÄka inet adr:127.0.0.1 Maska:255.0.0.0 inet6-adr: ::1/128 Rozsah:PoÄÃtaÄ AKTIVOVÃNO SMYÄKA BÄŽà MTU:16436 Metrika:1 RX packets:10945 errors:0 dropped:0 overruns:0 frame:0 TX packets:10945 errors:0 dropped:0 overruns:0 carrier:0 kolizÃ:0 délka odchozà fronty:0 PÅijato bajtů: 931884 (931.8 KB) Odesláno bajtů: 931884 (931.8 KB) ppp0 Link encap:Point-to-Point Protokol inet adr:192.168.10.41 P-t-P:204.232.203.12 Maska:255.255.255.255 AKTIVOVÃNO POINTOPOINT BÄŽà NEARP MULTICAST MTU:1400 Metrika:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 kolizÃ:0 délka odchozà fronty:3 PÅijato bajtů: 96 (96.0 B) Odesláno bajtů: 178 (178.0 B) root@duron650:/etc/bind# system log od VPN comming up Apr 8 18:52:16 duron650 NetworkManager[669]: info Starting VPN service 'org.freedesktop.NetworkManager.pptp'... Apr 8 18:52:16 duron650 NetworkManager[669]: info VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 5718 Apr 8 18:52:16 duron650 NetworkManager[669]: info VPN service 'org.freedesktop.NetworkManager.pptp' appeared, activating connections Apr 8 18:52:16 duron650 NetworkManager[669]: info VPN plugin state changed: 1 Apr 8 18:52:16 duron650 NetworkManager[669]: info VPN plugin state changed: 3 Apr 8 18:52:16 duron650 NetworkManager[669]: info VPN connection 'VPN on Demand' (Connect) reply received. Apr 8 18:52:16 duron650 pppd[5720]: Plugin /usr/lib/pppd/2.4.5//nm-pptp-pppd-plugin.so loaded. Apr 8 18:52:17 duron650 pppd[5720]: pppd 2.4.5 started by root, uid 0 Apr 8 18:52:17 duron650 modem-manager: (net/ppp0): could not get port's parent device Apr 8 18:52:17 duron650 NetworkManager[669]:SCPlugin-Ifupdown: devices added (path: /sys/devices/virtual/net/ppp0, iface: ppp0) Apr 8 18:52:17 duron650 NetworkManager[669]:SCPlugin-Ifupdown: device added (path: /sys/devices/virtual/net/ppp0, iface: ppp0): no ifupdown configuration found. Apr 8 18:52:17 duron650 pppd[5720]: Using interface ppp0 Apr 8 18:52:17 duron650 pppd[5720]: Connect: ppp0 -- /dev/pts/2 Apr 8 18:52:17 duron650 pptp[5725]: nm-pptp-service-5718 log[main:pptp.c:314]: The synchronous pptp option is NOT
Re: BIND9 fails resolving after connecting to VPN
Hi-- On Apr 8, 2011, at 10:27 AM, kapetr wrote: After connect to them (new network device created - tun or tap and default route changes) my BIND is not able to reach other (root) nameservers. And resolve requests fails. This is due to how you are operating your VPN. Change it to only add a route for the subnet of the remote end rather than making it change your default route: http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bogus Wild Card DNS
On Apr 8, 2011, at 10:58 AM, Martin McCormick wrote: I am trying to set up bind9.7.2P3 in a special manner such as is used in network registration setups in which named always returns the address of a registration server except for a few other domains that supply updates and antivirus scans, etc. In this case, I have microsoft.com as the one allowed domain and everything else should return the wild card A record. What is happening right now is that the one special allowed domain works fine and all else returned a SERVFAIL rather than resolving to what will eventually be the registration server. The microsoft allowed zone is defined in named.conf with forwarders My understanding is that the only real zone one needs is the hint zone or . and here is mine: @ IN NS netreg.it.okstate.edu. microsoft.com. IN NS netreg.it.okstate.edu. * IN A 139.78.6.193 Why am I not getting resolution to 139.78.6.193 for any other query? The log isn't complaining about much of anything but any query that is not microsoft returns that SERVFAIL message. I must remind anybody experimenting with something like this to be sure to put a bogus DNS clause in your functional production DNS's so that anything that might somehow leak out of this experiment is treated as junk and ignored. Many thanks. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Telecommunications Services Group ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users I think you want a *.com entry as well as the * entry. The existence of the 'microsoft.com.' record, believe it or not, affects whether names of the form whatever.com match the * A record. DNS's rules for wildcarding have been known to trip up a lot of people, so look for a full explanation. John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: priority with A record?
All the previously-mentioned issues apply, but (obviously) round robin could be made to offer a select server twice as often by giving that server an additional address and A record. Something similar for nameservers could be devised. I had a vague recollection that one could simply duplicate an A record in the zone file, but perhaps my memory is playing tricks on me. John W ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bogus Wild Card DNS
John Wobus writes: I think you want a *.com entry as well as the * entry. I have now put in an entry like: *.com. IN A 139.78.6.193 I still have the same behavior as before. The allowed domain succeeds and all others get a SERVFAIL where they should resolve to 139.78.2.193 which is the registration server. Right now, there is named.conf which has the allowed domain clause listing the forwarders. The only other file in the configuration is db.wildcard which is the root zone. That takes care of the allowed domains and is where the wild card records live. Are there are any other zones that should be there? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 fails resolving after connecting to VPN
Hello, I absolutely do not understand your answer. I use the VPT to anonymisation. I need all traffic to go over the VPN. Not just packets to LAN of VPN. I am not interesting at all about communication with other PCs in that VPN. The VPN must be used as target - default route. It is standard in usage of such services, it is what I need and want. I thing in fact, that the problem with BIND has nothing common with things around VPN. BIND simple get crazy when new net device is added and/or routes are changed. All apps use this new route, why BIND not ?! That is the question. Thanks --kapetr --- PŮVODNÍ ZPRÁVA - Od: Chuck Swiger cswi...@mac.com Komu: kapetr kap...@mizera.cz Předmět: Re: BIND9 fails resolving after connecting to VPN Datum: 8.4.2011 - 19:39:36 Hi-- On Apr 8, 2011, at 10:27 AM, kapetr wrote: After connect to them (new network device created - tun or tap and default route changes) my BIND is not able to reach other (root) nameservers. And resolve requests fails. This is due to how you are operating your VPN. Change it to only add a route for the subnet of the remote end rather than making it change your default route: http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyway to disable dns_zone_nscheck in 9.8.0?
On 4/8/2011 5:07 AM, Rodney Hives wrote: When you have hundreds / thousands of existing zones (from shared hosting) from users it is sometimes impossible to go in a fix all of the mistakes. s/impossible/a matter of actually doing the work/ Please stop foisting your broken stuff on the rest of the Internet. In the amount of time you've spent discussing this on the list you could have fixed several dozen of those broken zones. :) By actually fixing this you will also be doing your customers a favor, as well as reducing support calls. Everybody wins. Doug (and yes, I speak from extensive experience) -- 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: BIND9 fails resolving after connecting to VPN
On Apr 8, 2011, at 1:07 PM, kapetr wrote: I absolutely do not understand your answer. OK. I use the VPT to anonymisation. I need all traffic to go over the VPN. OK. That's not the usual method of operation for a routed VPN, but is more commonly used when doing bridging. The VPN must be used as target - default route. It is standard in usage of such services, it is what I need and want. It's not standard behavior, but if it is what you want, very well. I thing in fact, that the problem with BIND has nothing common with things around VPN. BIND simple get crazy when new net device is added and/or routes are changed. All apps use this new route, why BIND not ?! The kernel routing table (disciplined by static routing entries, or routed, BGP, OSPF, etc) and possibly firewall forwarding rules determine where network traffic is sent. There's nothing which would cause BIND to behave any differently than any other userland app which is not tweaking the routing table. This implies that there may be firewall rules in place between you and the VPN endpoint which are breaking DNS and/or EDNS0 aka RFC-2671. What does: dig +short rs.dns-oarc.net txt ...do when your VPN tunnel is up? Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 fails resolving after connecting to VPN
Thanks for replay, The VPN must be used as target - default route. It is standard in usage of such services, it is what I need and want. It's not standard behavior, but if it is what you want, very well. I had mean only standard in usage of such services - all of them do that so. There's nothing which would cause BIND to behave any differently than any other userland app which is not tweaking the routing table. This implies that there may be firewall rules in place between you and the VPN endpoint which are breaking DNS and/or EDNS0 aka RFC-2671. I have only 2 services get partially to work - one PPTP, one OpenVPN - at both the same problem with BIND. What does: dig +short rs.dns-oarc.net txt ...do when your VPN tunnel is up? After VPN up and restart of BIND: hugo@duron650:~$ dig +short rs.dns-oarc.net txt ;; connection timed out; no servers could be reached hugo@duron650:~$ Thanks --kapetr ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 fails resolving after connecting to VPN
If you think that the adding of a new route is the issue, then just restart named. As I wrote - it do not help. It might help if you post your named.conf to see if you have something wrong set in there. In attachment. (BTW - I have try it also without DNSSEC adds - so with out of the box config). Thanks --kapetr named.tar Description: Unix tar archive ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND9 fails resolving after connecting to VPN
On Apr 8, 2011, at 2:23 PM, kapetr wrote: What does: dig +short rs.dns-oarc.net txt ...do when your VPN tunnel is up? After VPN up and restart of BIND: hugo@duron650:~$ dig +short rs.dns-oarc.net txt ;; connection timed out; no servers could be reached hugo@duron650:~$ Hmm. Your local nameservers probably are listed in /etc/resolv.conf, otherwise consider adding @localhost or whatever is needed to talk to them. Something is blocking DNS traffic going via your tunnel, presumably. tcpdump and traceroute might help diagnose. Or try switching to hitting 4.2.2.2 or some other well-known public nameserver via dig, and see whether you can get a response from them. Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind and DLZ support
the implementation of resolution dnssec for the bind dns dry this natively in the distribution centos 5.5 is feasible try a simple config Le vendredi 08 avril 2011 à 18:38 +0200, fddi a écrit : Hello, I was trying to add DLZ support to bind on CentOS 5.5 so it's bind-9.3.6-4.P1.el5_5 I found out that the CentOS rpm does not have DLZ support built in and trying to patch bind manually the patch looks like to be for 9.2.2 version so it does not work on 9.3.6 anyone has a solution on how to add DLZ support to stock CentOS bind, or to add DLZ patch support to any recent bind version ? thank you Rick ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
