Re: BIND 9.7 Serial Number Decrease Problem
On 06/06/2011 08:01 PM, Barry Finkel wrote: Phil Mayers suggested a corrupt .jnl file; I am not sure. How do I debug this? Given what Mark has said, I think it's unlikely; I didn't realise bind wrote a new journal and did a rename() which is atomic on every POSIX system that you're likely to be using. So, ignore what I said! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 Serial Number Decrease Problem
In my last posting I was confused as to the .jnl file. I have about 44 AD slave files on my BIND servers, and 40 .jnl files. The two zones in question do not have .jnl files. As I do not look at .jnl files much, I had forgotten about the tool to list them. I now have this situation on one Solaris 10 slave; the problem probably also exists on the other Sol 10 slave and the two Ubuntu hardy slaves: The _tcp zone on the master MS DNS Server: 1238 600 86400 3600 The _tcp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 1239 ; serial 900; refresh (15 minutes) 600; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) The _udp zone on the master MS DNS Server: 842 900 600 86400 3600 The _udp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 843; serial 900; refresh (15 minutes) 600; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) Note that the zone serial number for both zones on the master is one LESS than the serial number on the slave. The last messages in /var/adm/messages are _tcp: Jun 4 07:46:57 serial number (1238) received from master ... ours (1239) Jun 4 07:47:35 zone ... expired Jun 4 07:47:35 zone ... transfer started Jun 4 07:47:35 zone ... transferred serial 1238 Jun 4 07:47:35 zone ... Transfer completed: ... _udp: Jun 4 07:39:22 serial number (842) received from master ... ours (843) Jun 4 07:42:22 zone ... expired Jun 4 07:42:22 zone ... transfer started Jun 4 07:42:22 zone ... transferred serial 842 Jun 4 07:42:22 zone ... Transfer completed There was a zone serial number mismatch, each zone expired three days ago, and new zones were transferred from the master. But the zone files on disk still have the higher serial numbers. There are no .jnl files on the disk. A dig on the server for the zone serial numbers shows the lower numbers, so BIND has those correct serial numbers. I assume that if I stopped BIND (rndc stop) and restarted it, then I would again see the serial number mismatches. I can try this during the day, as this server is not heavily used. Is there any debugging I need to run? Thanks. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
where is the bind 9.4-ESV-R4-P1?
Hi, i can't find the version 9.4-ESV-R4-P1 even here: http://ftp.isc.org/isc/bind9/ Last week this version was on the website(http://www.isc.org/downloads/all). why they remove it? I know it's EOL but at least i have to find it here http://ftp.isc.org/isc/bind9/ Thanks Issam HARRATHI IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles et peuvent etre protegees par la loi. Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus. Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler a l expediteur et effacer ce message et tous les fichiers eventuellement attaches. Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite. Tout message electronique est susceptible d alteration. A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie. De meme, il appartient au destinataire de s assurer de l absence de tout virus. IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is intended only for the named recipient(s) above. If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message. Any unauthorized view, usage or disclosure ofthis message is prohibited. Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified. Additionally the recipient should ensure they are actually virus free. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 Serial Number Decrease Problem
On 6/7/11 7:51 AM, Barry Finkel bsfin...@anl.gov wrote: There was a zone serial number mismatch, each zone expired three days ago, and new zones were transferred from the master. But the zone files on disk still have the higher serial numbers. There are no .jnl files on the disk. A dig on the server for the zone serial numbers shows the lower numbers, so BIND has those correct serial numbers. If you have multiple masters for which this server is a slave, then check the serial number on all of the masters. I think you will find that one of them is higher than the other... I assume that if I stopped BIND (rndc stop) and restarted it, then I would again see the serial number mismatches. I can try this during the day, as this server is not heavily used. Is there any debugging I need to run? Thanks. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 Serial Number Decrease Problem
On 07/06/11 13:51, Barry Finkel wrote: In my last posting I was confused as to the .jnl file. I have about 44 AD slave files on my BIND servers, and 40 .jnl files. The two zones in question do not have .jnl files. As I do not look at .jnl files much, I had forgotten about the tool to list them. I now have this situation on one Solaris 10 slave; the problem probably also exists on the other Sol 10 slave and the two Ubuntu hardy slaves: The _tcp zone on the master MS DNS Server: 1238 600 86400 3600 The _tcp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 1239 ; serial As Dan McDonald mentioned - the AD integrated DNS zones do not maintain a stable serial number, and in fact return a per-AD-controller SOA statement. Are you sure that isn't the cause of your problem? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Random Whois and Dig Fails
On Fri, Jun 03, 2011 at 03:09:13PM -0700,
Sri Harsha Yalamanchili har...@thought-matrix.com wrote
a message of 145 lines which said:
o query-source address X.X.X.X port 53;
That's typically a very bad idea because it makes the source port
predictable and therefore makes you much more vulnerable to the
Kaminsky vulnerability.
forwarders {
66.7.224.17; //Telepacific's DNS server
};
Did you try this forwarder with, for instance, dig? Does it really
work?
* The whois lookup works as long as we're telepacific's dns
server.
I don't really understand the sentence but, anyway, remember that
whois and DNS are two different and unrelated protocols. I suggest to
debug them separately.
We can clearly see that the queries are going out from the query
log.
BIND logs the outgoing queries? I didn't know. Anyway, I suggest using
tcpdump to see what is really going in and out.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.7 Serial Number Decrease Problem
McDonald, Dan dan.mcdon...@austinenergy.com replied to my posting: I think your root problem is trying to deal with active directory integrated zones. We stopped using them entirely when we found that each domain controller maintains an individual SOA record with its own serial number. The serial numbers rapidly (and purposely) fall out of sync, but active directory doesn't care as they use a different replication method. The only way that we could successfully interact from bind was to set up a forward-only zone and try to cache the results. When we found that Active directory under windows 2000 was unable to maintain proper synchronization, we switched to bind for all zones and haven't looked back. If you check the list archives (back to the days when there was bind-users and bind9-users), you will find my postings dealing with MS article 282826. MS details the problem with zone serial numbers, and that is why we run the DNS Server on only ONE Domain Controller (and have since the beginning of AD in Windows 2000). When we run the DNS Server on a second DC (because the Windows admins want to), I tell BIND that there is ONE master server. I do not care what the zone serial number is on the other DC DNS Server, unless we have to switch masters. The only times I have switched is when the master DC is being upgraded, and I switch to another DC as the master. We have NO machines cofigured (as far as I know) to use the DNS Servers on the DC as primary DNS servers; all machines are configured to use the BIND slaves. In the early days of AD, there were serial number decreases in the MS code. I had an open trouble ticket for a long time before the MS DNS development team found the problem. I have not had a serial number decrease on the MS side for a long time except, occasionally, when patches are being applied to the DC, the serial number on one or more zones will decrease during the patch run, but after the DC is rebooted, the serial number goes back to a non-decrease normal. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.6.1-P3 Vulnerabilities
BIND 9.6.1-P3 seems to be a somewhat old release of BIND, and yet, I can find no vulnerabilities listed on the ISC Security Advisories pages. Am I missing something? Regards, Joe Joseph A. Borgia, Jr. Network Services Team Lead Team Rome IT - NCI Information Systems CompTIA - Security+ Certified Oracle Solaris Certified Professional U.S. Air Force Research Laboratory/Rome Research Site/RIOS COMM: 315-330-3952 DSN: 587-3952 FAX: 315-330-8258 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Random Whois and Dig Fails
The query-source address is nat'ed address inside the firewall. We opted
for that to make our firewall less porous but may be we should re-visit
that strategy.
The forwarder actually works. That was the primary/only DNS server we
were using until we decided to install our own internal dns and delegate
non-internal DNSqueries to that particular forwarder - 66.7.224.17.
Yes we will try to debug Whois and DNS separately. But were just curious
about the strange behavior that seems to be connected to us changing the
DNS servers.
As for logging bind queries, here's a line in our named.conf.log that
does the logging:
category queries { query_log; };
Not much luck using tcpdump either. We know, from both the query_log and
tcpdump logging, that the queries are going out. But we never get a
reply back. That's the confusing part. The Google DNS server replies
back but not our own ISP's DNS. It times out multiple times before
replying once if at all.
Thank you,
--
Harsha
On 6/7/11 7:57 AM, Stephane Bortzmeyer wrote:
On Fri, Jun 03, 2011 at 03:09:13PM -0700,
Sri Harsha Yalamanchilihar...@thought-matrix.com wrote
a message of 145 lines which said:
o query-source address X.X.X.X port 53;
That's typically a very bad idea because it makes the source port
predictable and therefore makes you much more vulnerable to the
Kaminsky vulnerability.
forwarders {
66.7.224.17; //Telepacific's DNS server
};
Did you try this forwarder with, for instance, dig? Does it really
work?
* The whois lookup works as long as we're telepacific's dns
server.
I don't really understand the sentence but, anyway, remember that
whois and DNS are two different and unrelated protocols. I suggest to
debug them separately.
We can clearly see that the queries are going out from the query
log.
BIND logs the outgoing queries? I didn't know. Anyway, I suggest using
tcpdump to see what is really going in and out.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Random Whois and Dig Fails
On Jun 7, 2011, at 11:07 AM, Sri Harsha Yalamanchili wrote: Not much luck using tcpdump either. We know, from both the query_log and tcpdump logging, that the queries are going out. But we never get a reply back. That's the confusing part. The Google DNS server replies back but not our own ISP's DNS. It times out multiple times before replying once if at all. It sounds like this Telepacific nameserver at IP 66.7.224.17 is broken. The simple solution is to not use any forwarders entry, or to pick another one which works. Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
MX record IP address instead of hostnames
Can anyone tell me why my MX record for the coop-uspto.gov domain are IP addresses instead of hostnames? [klear@dns1 conf]$ nslookup set type=mx coop-uspto.gov Server: 10.240.11.20 Address:10.240.11.20#53 Non-authoritative answer: coop-uspto.gov mail exchanger = 5 151.207.128.23.coop-uspto.gov. coop-uspto.gov mail exchanger = 5 151.207.128.22.coop-uspto.gov. Authoritative answers can be found from: coop-uspto.gov nameserver = dr-coopdns-1.coop-uspto.gov. dr-coopdns-1.coop-uspto.gov internet address = 151.207.240.200 Here is the zone file for coop-uspto.gov [klear@dr-coopdns-1 named]$ more db.coop-uspto $TTL 7200 @ IN SOA dr-coopdns-1.coop-uspto.gov. nmb.uspto.gov. ( 2011060708 ; serial number /mm/dd/## format 10800 ; refresh after 3 hour 3600; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL 1 day IN NS dr-coopdns-1.coop-uspto.gov. localhost IN A 127.0.0.1 dr-coopdns-1IN A 151.207.240.200 dr-idns-1 IN A 151.207.128.33 ;COOP-USPTO MX record coop-uspto.gov. IN MX 5 coop-mbxhc-0.coop-uspto.gov. ;coop-mbxhc-0IN MX 5 coop-mbxhc-0.coop-uspto.gov. ;coop-mbxhc-1IN MX 5coop-mbxch-1.coop-uspto.gov. coop-uspto.gov. IN MX 5 coop-mbxhc-1.coop-uspto.gov. mailer IN A 151.207.128.131 ;www www IN A 151.207.128.134 @ IN A 151.207.128.134 coop-uspto-srv1 IN A 151.207.128.134 coop-dc-0 IN A 151.207.128.20 coop-dc-1 IN A 151.207.128.21 coop-mbxhc-0IN A 151.207.128.22 webmail IN A 151.207.128.22 webmail IN A 151.207.128.23 autodiscover IN A 151.207.128.22 autodiscover IN A 151.207.128.23 coop-mbxhc-1IN A 151.207.128.23 Thanks, k Karen Lear Evolver EUS - Network Operations Phone: 571-272-5314 email: karen.l...@uspto.gov ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX record IP address instead of hostnames
On 06/07/2011 08:31 PM, Lear, Karen (Evolver) wrote: Can anyone tell me why my MX record for the coop-uspto.gov domain are IP addresses instead of hostnames? [klear@dns1 conf]$ nslookup As of right now, that's not what I see: ;; ANSWER SECTION: coop-uspto.gov. 7200IN MX 5 coop-mbxhc-1.coop-uspto.gov. coop-uspto.gov. 7200IN MX 5 coop-mbxhc-0.coop-uspto.gov. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: MX record IP address instead of hostnames
Karen Lear wrote: Can anyone tell me why my MX record for the coop-uspto.gov domain are IP addresses instead of hostnames? ... Non-authoritative answer: coop-uspto.gov mail exchanger = 5 151.207.128.23.coop-uspto.gov. coop-uspto.gov mail exchanger = 5 151.207.128.22.coop-uspto.gov. I can't, no. It looks fine enough when I check here (a bit odd to only have a single nameserver, but that's beside the point). [eivind@vimes ~]$ dig +short mx coop-uspto.gov 5 coop-mbxhc-1.coop-uspto.gov. 5 coop-mbxhc-0.coop-uspto.gov. [eivind@vimes ~]$ Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: MX record IP address instead of hostnames
Thanks. From: bind-users-bounces+karen.lear=uspto@lists.isc.org [bind-users-bounces+karen.lear=uspto@lists.isc.org] On Behalf Of Eivind Olsen [eiv...@aminor.no] Sent: Tuesday, June 07, 2011 5:38 PM To: bind-users@lists.isc.org Subject: Re: MX record IP address instead of hostnames Karen Lear wrote: Can anyone tell me why my MX record for the coop-uspto.gov domain are IP addresses instead of hostnames? ... Non-authoritative answer: coop-uspto.gov mail exchanger = 5 151.207.128.23.coop-uspto.gov. coop-uspto.gov mail exchanger = 5 151.207.128.22.coop-uspto.gov. I can't, no. It looks fine enough when I check here (a bit odd to only have a single nameserver, but that's beside the point). [eivind@vimes ~]$ dig +short mx coop-uspto.gov 5 coop-mbxhc-1.coop-uspto.gov. 5 coop-mbxhc-0.coop-uspto.gov. [eivind@vimes ~]$ Regards Eivind Olsen ___ 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: MX record IP address instead of hostnames
I suspect a operator error that has now been fixed. If you put IP addresses in the MX records, instead of hostnames, the current $ORIGIN will be appended which is born out by looking at the address records for the mail exchangers. Mark [drugs:~/cvs/bind9] marka% dig mx coop-uspto.gov ; DiG 9.6.0-APPLE-P2 mx coop-uspto.gov ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 39502 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 3 ;; QUESTION SECTION: ;coop-uspto.gov.IN MX ;; ANSWER SECTION: coop-uspto.gov. 7157IN MX 5 coop-mbxhc-0.coop-uspto.gov. coop-uspto.gov. 7157IN MX 5 coop-mbxhc-1.coop-uspto.gov. ;; AUTHORITY SECTION: coop-uspto.gov. 2983IN NS dr-coopdns-1.coop-uspto.gov. ;; ADDITIONAL SECTION: coop-mbxhc-0.coop-uspto.gov. 7187 INA 151.207.128.22 coop-mbxhc-1.coop-uspto.gov. 7196 INA 151.207.128.23 dr-coopdns-1.coop-uspto.gov. 2984 INA 151.207.240.200 ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 8 10:34:14 2011 ;; MSG SIZE rcvd: 165 [drugs:~/cvs/bind9] marka% In message 2aa71bedebcf80449e35b7b640700be4364424e...@email4.uspto.gov, Lear , Karen (Evolver) writes: Thanks. From: bind-users-bounces+karen.lear=uspto@lists.isc.org [bind-users-bounc es+karen.lear=uspto@lists.isc.org] On Behalf Of Eivind Olsen [eivind@amin or.no] Sent: Tuesday, June 07, 2011 5:38 PM To: bind-users@lists.isc.org Subject: Re: MX record IP address instead of hostnames Karen Lear wrote: Can anyone tell me why my MX record for the coop-uspto.gov domain are IP addresses instead of hostnames? ... Non-authoritative answer: coop-uspto.gov mail exchanger = 5 151.207.128.23.coop-uspto.gov. coop-uspto.gov mail exchanger = 5 151.207.128.22.coop-uspto.gov. I can't, no. It looks fine enough when I check here (a bit odd to only have a single nameserver, but that's beside the point). [eivind@vimes ~]$ dig +short mx coop-uspto.gov 5 coop-mbxhc-1.coop-uspto.gov. 5 coop-mbxhc-0.coop-uspto.gov. [eivind@vimes ~]$ Regards Eivind Olsen ___ 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 -- 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
second nameserver with two IPs
Hello, My second nameserver has tow IPs, for example, 61.144.56.1 61.144.57.1 (They are in different CIDRs.) and my ns2.example.com was pointed to these two IPs. Will this cause problems, for example, the duplicated notification or zone-transfer? Thanks in advance. Receive Notifications of Incoming Messages Easily monitor multiple email accounts access them with a click. Visit http://www.inbox.com/notifier and check it out! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS is tainted
Hello, From the dig info below: C:\digdig +nocmd www.nsbeta.info +noall +answer @ns1.google.com www.nsbeta.info.3497IN CNAME nsbeta.info. nsbeta.info.2434IN A 74.117.232.204 C:\digdig +nocmd www.nsbeta.info +noall +answer @ns1.google.com www.nsbeta.info.3492IN CNAME nsbeta.info. nsbeta.info.2429IN A 74.117.232.204 C:\digdig +nocmd www.nsbeta.info +noall +answer @ns1.google.com www.nsbeta.info.3486IN CNAME nsbeta.info. nsbeta.info.2423IN A 74.117.232.204 I think my office network's DNS is tainted. because: 1) ns1.google.com is authoritative nameserver only, which shouldn't answer this query. 2) the TTL is decreased each time, if it's a real authority answer, the TTL should be all the same. And this is the full output of dig: C:\digdig www.nsbeta.info @ns1.google.com ; DiG 9.3.2 www.nsbeta.info @ns1.google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1183 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.nsbeta.info. IN A ;; ANSWER SECTION: www.nsbeta.info.3111IN CNAME nsbeta.info. nsbeta.info.2048IN A 74.117.232.204 ;; Query time: 15 msec ;; SERVER: 216.239.32.10#53(216.239.32.10) ;; WHEN: Wed Jun 08 11:09:09 2011 ;; MSG SIZE rcvd: 74 How to deal with this case? Thanks. Regards. FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
