Re: BIND not loading into memory on first transfer
What's the SOA? It's possible that the zones were not expired, so they were provided as saved on disk. Since BIND wasn't able to transfer newer versions, it continued providing old versions. On 26.03.15 12:48, Frank Even wrote: Yes, the old versions were provided on disk on initial load. But that was then followed up with a SUCCESSFUL zone transfer minutes later, but the server was unable to save the tmp file in the working directory and served stale content until about 2 hours later when the server was able to get another successful zone transfer from the master and then loaded the new zone in memory (despite being unable to write the tmp file to update the local copy of the zone). what didthe logs say? Looks like the first transfer wasn't really successful (or the zone was rejected) On 26.03.15 14:48, Frank Even wrote: Logs indicated successful transfer, permission denied writing the tmp-x file that happens prior to writing it out to the zone file itself. and how do hey differ from the second transfer? If they don't itmay be a bug (or a "bug") in named that it behaves differently after first and other 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. M$ Win's are shit, do not use it ! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND not loading into memory on first transfer
On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote: > The subject is about the only way I can think to describe a > situation we've run into recently. First here is the system: > > [root@dns]# cat /etc/redhat-release > CentOS release 6.6 (Final) > [root@dns]# rpm -q bind > bind-9.8.2-0.30.rc1.el6_6.2.x86_64 > > So, we got bit by a chroot permissions issue (unsure exactly how it > got introduced), where the chroot was owned by root, but had named > as the group owner. Perms were 750 on the dir (rwxr-x---) > > Zone files were in place for the necessary domains, but were > outdated (assuming one of our updates broke something somewhere, > they were all on average 3 months old). > > We updated some of the boxes, and on restart, named started. > > It initially started loading the 3 month old zone (one frequently > updated I might add). The boxes then did a zone transfer from the > master. Failing to be able to write the tmp file to the working > directory, it moved on. Slave and other dynamic zones do require write privilege in the working directory. Have you fixed this problem yet? If you're running as user "named", that's the user which must have write privilege. If running as root, root must have explicit privilege to write, because named drops superuser capabilities. I suspect the problem might be SELinux. Check "getenforce", and perhaps restore the context to the working directory (see "man restorecon") or disable SELinux if you prefer. > Here is where the issue is. I've generally found if BIND fails to > write the zone, it generally loads it into memory (masking the fact > that there is an issue here for an extended period of time). named makes a best effort to get up and running, which it ought to do, IMO. It's not masking anything; the inability to write to the working directory has been logged. > In this particular instance, the masters ended up under maintenance > shortly after these boxes rebooted, so they were unable to transfer > the zone from them for another 2 hours. These boxes were serving > stale data after boot despite being able to accomplish one zone > transfer after boot. It seems that failing the first zone transfer > did NOT load the zone into memory (but subsequent zone transfers > while still failing to write the tmp file DID load the zone into > memory). > > I guess the question really is, is this expected behavior or a bug? The bug is a misconfiguration bug, where contrary to documented requirements, you have not given named write privilege in its directory. I think you're saying named should fail to load the stale zones, which at startup it cannot know are stale. That does not sound correct to me. Perhaps you're suggesting that named should SERVFAIL the zone when the first zone transfer has happened, and while this sounds more reasonable, I am not sure that the zone transfer actually does take place if named is unable to open a temporary file to write. (What would be the point in talking to the master when you know you are unable to handle the data?) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND not loading into memory on first transfer
In article , /dev/rob0 wrote: > On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote: > > In this particular instance, the masters ended up under maintenance > > shortly after these boxes rebooted, so they were unable to transfer > > the zone from them for another 2 hours. These boxes were serving > > stale data after boot despite being able to accomplish one zone > > transfer after boot. It seems that failing the first zone transfer > > did NOT load the zone into memory (but subsequent zone transfers > > while still failing to write the tmp file DID load the zone into > > memory). > > > > I guess the question really is, is this expected behavior or a bug? > > The bug is a misconfiguration bug, where contrary to documented > requirements, you have not given named write privilege in its > directory. > > I think you're saying named should fail to load the stale zones, > which at startup it cannot know are stale. That does not sound > correct to me. > > Perhaps you're suggesting that named should SERVFAIL the zone when > the first zone transfer has happened, and while this sounds more > reasonable, I am not sure that the zone transfer actually does take > place if named is unable to open a temporary file to write. (What > would be the point in talking to the master when you know you are > unable to handle the data?) He's not suggesting either of these. He's saying that when it successfully transferred the zone, it should update the in-memory version, and serve that, even though it wasn't able to save it to disk. That's what it does on the SECOND transfer, it just doesn't do it on the FIRST transfer. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: behavior of dnssec-enable in relation to dnssec-validation
On Tue, Mar 24, 2015 at 10:50:42PM -0400, b...@bitrate.net wrote: > in the arm, it says "dnssec-enable: Enable DNSSEC support in named. > Unless set to yes, named behaves as if it does not support > DNSSEC.". "behaves as if it does not support DNSSEC" seemed quite > unequivocal to me, so i interpreted this to mean that if > dnssec-enable no; is set, no dnssec operations/behavior of any kind > would be seen, period, regardless of what other settings might be > set. however, it seems that if dnssec-validation auto; is set [i > didn't try dnssec-validation yes;], bind does perform dnssec > related operations even though dnssec-enable no; is set [from > looking briefly at logs with rndc trace 1, i see what appear to be > attempts at validation - retrieving ds records, dnskey records, > etc]. I tested this with a query of dnssec-failed.org/IN/SOA, and indeed, validation is done and (of course) fails. named-checkconf -p shows: dnssec-enable no; dnssec-lookaside auto; dnssec-validation auto; > am i misinterpreting the documentation? Reading on through: " dnssec-validation Enable DNSSEC validation in named. Note dnssec-enable also needs to be set to yes to be effective. ... " This does not seem to be the case. I think bug, whether it's the documentation or the behavior. > misinterpreting the apparent behavior? something else? -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Modify a Response
Hi, My name is John and I am new to Bind. I am planning to use Bind9 (as Auth server) is some Internet measurement experiment. What I want to do is to respond to each query that arrives to the Auth. server by a chain of CNAMEs (the CNAME will have some field depends of the requester position). I am not planning to use DNSSEC in this experiment. Can I do such thing? If yes, which module (C file) that I should deploy my changes to? Many Thanks ! John___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modify a Response
In message <974880497.19490.1427501061182.javamail.ya...@mail.yahoo.com>, John Selva writes: > > Hi, > My name is John and I am new to Bind. I am planning to use Bind9 (as Auth ser > ver) is some Internet measurement experiment. What I want to do is to respond > to each query that arrives to the Auth. server by a chain of CNAMEs (the CNA > ME will have some field depends of the requester position). I am not planning > to use DNSSEC in this experiment. Can I do such thing? If yes, which module > (C file) that I should deploy my changes to? > Many Thanks ! > John Compile with geoip support and use a dlz module with geoip support. See bin/tests/system/geoip for examples. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modify a Response
Thanks Mark for your response. Actually, I tried to access the example but I couldn't locate geoip directory. What I really want is to modify the C file that is related to the response action because the methodology that I want to use will be conditional (either respond with normal response with the CNAME format that II mentioned before). Thanks On Friday, March 27, 2015 8:45 PM, Mark Andrews wrote: In message <974880497.19490.1427501061182.javamail.ya...@mail.yahoo.com>, John Selva writes: > > Hi, > My name is John and I am new to Bind. I am planning to use Bind9 (as Auth ser > ver) is some Internet measurement experiment. What I want to do is to respond > to each query that arrives to the Auth. server by a chain of CNAMEs (the CNA > ME will have some field depends of the requester position). I am not planning > to use DNSSEC in this experiment. Can I do such thing? If yes, which module > (C file) that I should deploy my changes to? > Many Thanks ! > John Compile with geoip support and use a dlz module with geoip support. See bin/tests/system/geoip for examples. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
