Re: location for master file dump
On Sun, May 27, 2018 at 09:13:30AM +0100, André Rodier via bind-users wrote: > On Sat, 2018-05-26 at 22:45 +0100, André Rodier via bind-users wrote: > > On 2018-05-26 22:16, Anand Buddhdev wrote: > > > You've told BIND to load zones from /etc/bind, so it will try > > > to create the journal files in the same directory, despite the > > > "directory" option. > > > > > > You'll need to move your zones into /var/cache/bind, or a > > > subdirectory thereof. > > > > Thank you, Anand, > > > > It is something I am reluctant to do, I have already started to > > explore other servers. > > Thanks for your help, sorry for the answer yesterday, I was pretty > upset by this limitation. No worries, it is a good thing that we have multiple DNS implementations from which to choose. > In the end, I finally used /var/cache/bind as the directory for bind9, > and I do not have the error from AppArmor any more. Also, I did not > want to loose the time I invested in the configuration. > > However, I kept my domain definition file in /etc/bind, with read only > permissions, and used a symbolic link in /var/cache/bind. This is the > safest way I found to keep apart configuration and dynamic data. You're apparently misunderstanding what a zone file is. It's a data file, not a configuration file. It properly belongs under /var, not under /etc. > However, PowerDNS seems a good server I am willing to explore the > option. Indeed, and I know some PDNS developers; they're good folks and highly competent. -- 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: Queries regarding Master/Slave
On Sat, May 05, 2018 at 03:52:16PM +0530, Blason R wrote: > Since I am building Master/slave RPZ for my organization I do have > couple of queries. > > >1. My ixfr is not working as soon as I remove the statement it >works fine Remove WHAT statement? No data, no useful answer. >2. Do I need to create files at secondary server? or will those >be created automatically? Assuming the EUID/EGID running named (see if you're using -u) has write privilege in the specified file location, they will be created. Offer void where taxed or prohibited, or where you have shot yourself in the foot using SELinux or similar. >3. I guess I always need to change the serial number whenever I >am performing changes; is there any automated way to do that? You can use dynamic updates with nsupdate(8) or other RFC 2136 updating client. See "Dynamic updates" section of ARM chapter 4; also look for articles at the ISC KB: https://kb.isc.org/ >4. And is there any authentication method between master/slave? TSIG signatures can be used. This is also covered in ARM chapter 4, and I recommend using the HTML version, because it hyperlinks to relevant syntax documentation in chapter 6. And again, see the KB. TSIG can be used for any form of query, including the notify sent from master to slave[s]. See the section in ARM chapter 6, on "server Statement Grammar". -- 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: Fwd: Re: BIND Server running but not responding
On Wed, Apr 18, 2018 at 04:09:55PM +0100, Admin Hardy wrote: > So sorry about the rndc-key's secret. I think my BIND server is > internal only (no forwarding for 53 in my internet facing router) Your controls are only on 127.0.0.1:953, so port 53 is not involved, and 127.0.0.1 cannot be routed to on the Internet, so this is not really an urgent matter. > but what is a quick way for me to change/recreate the key/secret? See the rndc-confgen manual. -- 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: Queries to DNS Blackholes don't respond
On Wed, Apr 18, 2018 at 11:44:27AM -0300, Roberto Carna wrote: > Dear, I have impelmented a BIND9 server. It works OK, but some days > ago an application failed because it needed to resolve the reverse of > some IP addresses from range 10.x.x.x, and they waited for a long time > and failed, because they need a NXDOMAIN fast response. > > I don't want to make a local zone 10.IN-ADDR.ARPA, You don't need to. See the "built-in empty zones" section of the BIND 9 ARM, chapter 6. > because I want to > use the two public nameservers from Internet: > > BLACKHOLE-1.IANA.ORG (192.175.48.6) > BLACKHOLE-2.IANA.ORG (192.175.48.42) What?? Why? Those are not supposed to be used. BIND now includes empty zones for all RFC 1918 and other reserved netblocks which shouldn't ever appear on the open Internet. If you use some of these networks inside your organization, you can have authoritative zones for the corresponding in-addr.arpa zones. [snip] > Is it OK that I do? Are blackholes servers useful for this purpose ? Not at all. That's why we have the automatic empty zones. Sadly, many distributors are not aware of the feature, so they distribute named.conf with kludges. -- 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 Server running but not responding
On Wed, Apr 18, 2018 at 02:51:32PM +0100, Admin Hardy wrote: > I am requesting resolution for "rota.rotatesting.com" (see below) > > the full http request happens to be > "http://rota.rotatesting.com:8081/mywebapp/; > > The client software (browser) cannot resolve the name > I downloaded dedicated DNS Lookup software and the request times out > looks like the server is not responding with anything. > > Just two of the log files have logging. > > I would be really grateful if you could suggest possible causes: Sure. The logs report a lot of this: > 18-Apr-2018 14:14:21.649 could not listen on UDP socket: permission > denied Your OS denies named the permission to create the UDP socket on which to listen for queries. That means, of course, that you're not able to receive queries. It's Windows doing this, so you need Windows help. I'm unable to provide that. Good luck. -- 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
expired SSL certificate
The certificate for lists.isc.org expired today, and because of STS my browser does not allow a security exception. -- 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: Different forwarder for certain response ip (result ip )
On Sat, Sep 16, 2017 at 10:50:14AM +, Alberto Colosi wrote: > even on hotel . why not to use a BIND on unix or window > on ur box u r using ? > > it is so easy Ugh, this is a mailing list, please use real words and not TXT messaging / chat abbreviations. Thank you. No, it is not easy in many captive portals. I use a laptop for everything, and I tried it. Sometimes you MUST be using that portal's nameserver to "authenticate" or to be approved as a user. BIND logs will be flooded with gazillions of "lame server" messages, as every iterative query is answered with a non-authoritative reply. Of course it depends where you go, but for me, sometimes I find myself stuck behind portals like the OP found, which redirect all queries to broken nameservers. That said, for people with "normal" Internet providers, yes, it's very easy to run your own caching resolver. -- 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: Different forwarder for certain response ip (result ip )
On Sat, Sep 16, 2017 at 03:18:57AM -0700,
Omid Kosari via bind-users wrote:
> This is my first post to this mailing list .
And it's a classic example of "XY question": "I want to do X, and I
think Y will do it, so I ask how to do Y, although people more
familiar with the subject matter think that sounds like a very
strange thing to do."
> I have a caching bind dns server with forwarders like this .
> forwarders {
> 8.8.8.8;
> 8.8.4.4;
> };
Later in the thread we discovered that the ISP is redirecting all
queries on port 53 to their own nameservers which are broken in
various ways. I *think* they are hijacking NXDOMAIN responses,
returning their own ad server IP address for NXDOMAIN queries. But
you have failed (or refused) to provide this bit of information.
With redirected queries on port 53 TCP and UDP, the address of the
forwarder would not matter. It could be anything, as you showed
later in the thread.
> I want to use another forwarders if the response of the query is
> for example 1.2.3.4
And you munged the ISP's ad server, why, to protect their "privacy"?
Sadly, this protection possibly harms you, and possibly other users
who might otherwise be tempted to do business with that ISP. It
might make your quest more difficult, because if you had been open
about who/what you are dealing with, you might have found another
user who had come up with a different workaround for the problem.
No, this is not possible; named makes a query and cannot be
configured to redo the query based on its results. But you might be
interested in the deny-answer-* features of BIND. See the "Content
Filtering" section of ARM chapter 6 for your BIND version. This
content filtering would not repeat the queries, however.
See also dnsmasq(8) for a forwarding-only nameserver which
conditionally can ignore a certain result. As with named, it won't
repeat the query, however.
> I've found that rpz-ip is what i want
How so? Be more specific about the real problem and goal.
> but i was unable to create relation to forwarders .
Correct.
>//if response ip or rpz-ip = 1.2.3.4 then
> forwarders {
> 208.67.222.222 port 443;
> 208.67.220.220 port 443;
> };
So if you want to use opendns, why not just use those forwarders for
all queries? What benefit could there be in querying the ISP
nameservers first?
--
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: How to pause master zone updates to slave for couple of minutes
On Mon, Sep 04, 2017 at 05:06:32PM +0530, rams wrote: > I want to test bulk updates master to slave in Bind. Is there > any way to pause to send updates to slave from master? Lots of ways, I would think. One way might be to add "notify no;" in your zone or global options, then "rndc reconfig". When testing is completed, remove that and "rndc reload". -- 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: email notification in bind?
On Tue, Aug 29, 2017 at 06:14:51PM +0530, rams wrote: > Do we have email notification feature in Bind when zone update > fails. In addition to what Grant said, "No," in effect, you might want to clarify the problem and goal. Do you mean when updating zone data with nsupdate(1)? Or are you talking about a slave receiving a notify and pulling a zone transfer? "Zone update fails" is an ambiguous phrase. -- 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: filter-aaaa-on-v4 not available in Windows binary?
On Tue, Aug 29, 2017 at 02:12:43PM -0500, pLAN9 wrote: > I have downloaded the latest 9.11.2 BIND running on Windows 10 and > have set up a successful caching-only server. When I try to add > "filter--on-v4 yes" to the global "options" section of > named.conf, the Windows BIND service fails to start, with an event > viewer log entry stating a "Parsing error" on the line containing > the filter statement. I suspect you have a syntax error, or maybe non-ASCII characters in your named.conf. > Does this mean I will have to manually compile BIND on WIndows > for this option to work? There is no specific compile flag to enable that feature, so no. > I assume that I don't need a full version of Visual Studio > to compile, the free "Community" edition of VS 2017 will work? I think the Knowledge Base has an article on compiling BIND for Windows. But again, I doubt that could be the problem. -- 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: How do I reset a DNSSEC zone ?
On Sun, Aug 20, 2017 at 01:21:21PM +0200, Pierre Couderc wrote: > I did do it roughly on a test zone, by erasing the key and > erasing all zone.jnl, zone.signed, etc > > hoping come back to the initial status. But I get the message : > > dns_dnssec_keylistfromrdataset: error reading private key file > zone/RSASHA1/21477: file not found > > That is normal as I have erased it but how to get rid of this > message ? If named is configured to sign the zone, it will continue looking for your zone keys. If you need specific help with your named configuration, you would need to share it with us: "named-checkconf -px" (leave off "x" if you're using RHEL who like to stay back from useful "new" features added to software they distribute.) -- 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
[ot] Re: botched KSK rollover
On Fri, Aug 18, 2017 at 08:25:00AM -0700, Carl Byington wrote: > > Sigh, it sure would be nice if I had a registrar with a means > > to automate DS submission. > > You might want to look at gkg.net I've been planning to do that for a long time, I guess this is a reason to move on that. I was in chat with Godaddy support 90 minutes yesterday, trying to discover why the DS I entered was not being served by .US servers. Something was/is wrong with their DS handling, and I had proof, but they could not understand/believe it. After some time with the first tier, I asked to be escalated. And then I described the issue to the second tier: "Trying to enter a new DS for nodns4.us ... the old one, key tag 60073, is there, but not the new one, 16408." His reply floored me, but I suppose should not have been a surprise: "Sorry, what's DS?" :) https://www.godaddy.com/help/what-is-a-ds-record-6148 The discussion ended without satisfaction or acknowledgement of Godaddy's problem in DS handling, just the stock "wait for DNS 'propagation'" answer they probably give quite regularly. But in the meantime they must have had someone looking into the problem, because my new DS is now in place. Whew. My son joked, I should have told him, "DS stands for Disgusting Service, in Godaddy's case." I can think of a few other appropriate things, as well, which might not befit mention on this nice mailing list. :) -- 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
botched KSK rollover
Oops. I had it all figured out about 2 months ago and had generated new keys for ZSK (which I rolled over right away) and KSK. The KSK change was slated for yesterday, but I forgot to get the DS to the parent zone before the inactivation of the previous KSK. Sigh, it sure would be nice if I had a registrar with a means to automate DS submission. But it's my fault for failing to set a reminder to do it manually. I put a bandaid on the problem with dnssec-settime(8). With that I reactivated the old dead key (this has me feeling a bit like Frankenstein! :) ) I added a week to inactivation, # dnssec-settime -I+1w Knodns4.us.+005+60073.key I thought I should then try deactivating the new one, but dnssec-settime did not like what I tried: # dnssec-settime -i6d -S Knodns4.us.+005+60073.key Knodns4.us.+005+16408.key dnssec-settime: fatal: Predecessor will become inactive before the prepublication period ends. Either change its inactivation date, or use the -i option to set a shorter prepublication interval. I don't understand this error. 1w > 6d, right? At this time I have 3 RRSIGs for DNSKEY: from both KSKs and the ZSK. According to both DNSViz and Verisign's dnssec-debugger this has put me back in business for the time being. For some reason I am not successful in wrestling with Godaddy over the new DS, but that's not a matter for this list. -- 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: need to look up short names
On Thu, Aug 10, 2017 at 08:07:00PM -0600, Grant Taylor via bind-users wrote: > On 08/10/2017 06:21 PM, toddandmargo wrote: > > I am stumped. I need to be able to look up short names on my > > local network. > ... > > What am I missing? > > domain and / or search configuration in /etc/resolv.conf > > man resolv.conf Note that this still work for dig(1) and host(1) as per the OP's examples. But things like ping(1) and browsers will work with a search domain. -- 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-chroot, runs, works, dies
On Wed, Aug 09, 2017 at 03:14:00PM -0700, toddandmargo wrote: > Help! > > Fedora 26 x64 > Xfce 4.12 > > # rpm -qa \bind\* > bind-libs-lite-9.11.1-2.P2.fc26.x86_64 > bind99-libs-9.9.10-1.P2.fc26.x86_64 > bind-chroot-9.11.1-2.P2.fc26.x86_64 > bind-license-9.11.1-2.P2.fc26.noarch > bind-9.11.1-2.P2.fc26.x86_64 > bind-libs-9.11.1-2.P2.fc26.x86_64 > bind99-license-9.9.10-1.P2.fc26.noarch > bind-utils-9.11.1-2.P2.fc26.x86_64I have a weird one. I am trying > to set up bind-chroot. When I run it, it works for about 30 > seconds, then dies. And for the entire 30 seconds, it works > beautifully. I can go anywhere with Firefox and look up anything > with "host". Then it breaks my heart. Your mail client has a problem with line wrapping, which made this very difficult to read. > # systemctl start named-chroot Job for named-chroot.service > # canceled. This is my error logs: > Aug 8 15:58:49 FedoraServer named[10120]: all zones loaded Aug 8 > 15:58:49 FedoraServer named[10120]: running Aug 8 15:58:49 Yes, named seems to start and to be running fine. > FedoraServer named[10120]: zone 255.168.192.in-addr.arpa/IN: > sending notifies (serial 57) Aug 8 15:58:49 FedoraServer > named[10120]: zone alpine.local/IN: sending notifies (serial 60) > Aug 8 15:58:49 FedoraServer systemd: named-chroot.service: PID > file /var/named/chroot/run/named/named.pid not readable (yet?) > after start: No such file or directory Aug 8 16:00:19 FedoraServer > systemd: named-chroot.service: Start operation timed out. > Terminating. Your systemd, for some reason probably related to what it said, has killed named. > Aug 8 16:00:19 FedoraServer named[10120]: shutting > down Aug 8 16:00:19 FedoraServer named[10120]: stopping command > channel on 127.0.0.1#953 Aug 8 16:00:19 FedoraServer named[10120]: > stopping command channel on ::1#953 Aug 8 16:00:19 FedoraServer > named[10120]: no longer listening on ::#53 Aug 8 16:00:19 > FedoraServer named[10120]: no longer listening on 127.0.0.1#53 Aug > 8 16:00:19 FedoraServer named[10120]: no longer listening on > 50.124.80.106#53 Aug 8 16:00:19 FedoraServer named[10120]: exiting And named obediently did a clean shutdown. Your issue might more effectively be dealt with in a Fedora forum, or as a Fedora bug. -- 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: DNSSEC DS Record
On Fri, Jul 14, 2017 at 04:41:07PM -0400, sami's strat wrote: > What about the child zone? Do I need a DS record for the child No, not in the delegated zone. > zone as well? I see a good number of big DNS players in DNS (no > names) that do have DS records in there zones. Nothing will use it. > Does zbc.com (for example) need DS, or is just passed by the TLD? Zbc.com. is not a zone, it is a CNAME in the com. TLD. There would be no NS to delegate to, therefore no DS. -- 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:29:59AM -0500, /dev/rob0 wrote: > On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > > Thanks for your answer. There are no other records with that name > > in the zone, and an ANY query comes back empty but still with > > status of NOERROR. Unfortunately, I can't provide the query and > > zone data, and I do understand that prevents you from helping. > > > > I was hoping someone else had come across this at some point. > > I can continue to waste our time with guesses, however. :) > > Have you tried directed queries to an authoritative nameserver? > Today's guess is that you might be seeing some kind of caching > issue. Today's guess retracted, I just saw your followup. :) > Is the authoritative nameserver BIND? If so, what version? You might need to file a bug report (and as of now the bug database is entirely private; that will be changing soon, but if you ask them, ISC will keep your bug report private.) Of course, if the server in question is *not* BIND, you're in the wrong place to ask. :) -- 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: wildcard not working after record deleted
On Tue, Jun 20, 2017 at 09:17:58AM -0400, Maria Iano wrote: > Thanks for your answer. There are no other records with that name > in the zone, and an ANY query comes back empty but still with > status of NOERROR. Unfortunately, I can't provide the query and > zone data, and I do understand that prevents you from helping. > > I was hoping someone else had come across this at some point. I can continue to waste our time with guesses, however. :) Have you tried directed queries to an authoritative nameserver? Today's guess is that you might be seeing some kind of caching issue. A directed query like this: $ dig sample.example.com. any @ should return the wildcard if all records at "sample.example.com" have been removed. If in fact you were querying a caching resolver, is that BIND? Is the authoritative nameserver BIND? -- 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: wildcard not working after record deleted
On Mon, Jun 19, 2017 at 06:19:31PM -0400, Maria Iano wrote: > We have a group of users that need to use a wildcard record in > their zone. Their wildcard works in general, but they have a > situation where it isn't working. They had some records that they > deleted, and expected the wildcard to take over, but it hasn't. If > we query a record that doesn't exist and never has in the zone, > then we get the answer from the wildcard. If we query a record that > used to exist but was deleted and now doesn't exist, then we get no > answer. We don't get NXDOMAIN, we get NXDOMAIN means there is no data of any type for the queried owner name. > status: NOERROR > > and no answer. NOERROR means the query completed successfully, with no error. It might mean in your case that there is other data with that owner name, but no RRset of the requested type. IOW, when you have a TXT and A record with the same owner: sample 7200IN A 192.0.2.53 sample 7200IN TXT "This is a sample." * 7200IN A 192.0.2.101 If you delete the A record, the TXT is still there, and your wildcard A record in the zone would not be used for that name. > Has anyone else come across this? That's the best guess I can come up with without seeing the query and the zone data. If you need more help you will have to share that information. -- 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: Stop Reverse resolution query Logging
On Thu, Jun 01, 2017 at 04:28:23PM +0200, Job wrote:
> is there a way in Bind 9 to stop logging (to bind.log standard
> file) all the in-addr.arpa queries?
What "standard" is this? The default logging for named goes to
syslog, and from there it's up to your syslogd to decide if/where it
should be written.
Perhaps what you want is a separate log channel for queries? This is
what I use:
logging {
channel "default_log" {
file "logs/named.log" versions unlimited size 4194304;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
channel "query_log" {
file "logs/query.log" versions 10 size 2097152;
severity dynamic;
print-time yes;
};
category "default" {
"default_log";
};
category "queries" {
"query_log";
};
};
Those paths are relative to the "directory" which is set in your
options{}. Adjust to suit.
> We would like to log everything else but not the reverse
> resolution queries.
Why (and why not?) What's the actual problem? And what do you plan
to do with all those query logs? Query logging has a substantial
impact on server performance.
--
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: Catalog "reconfig" calamity
On Fri, May 26, 2017 at 03:24:40PM -0500, I wrote:
> To make the story easier to follow I'll use these names to refer to
> the servers in question:
> 1. "Master", the physical machine, BIND 9.10
> 2. "VM1"[1] the existing VM, former master of most zones
> 3. "VM2"[2] the new virtual machine
> Both VMs are running BIND 9.11.1, and all are on various versions of
> Slackware Linux.
>
> The plan is to migrate all masters to Master and to use catz to
> provision the two VMs. As I said, this is all peachy and smooth on
> VM2 (many thanks to Mukund and ISC for that.)
>
> I have run into trouble on VM1. My procedure has been to update the
> master zones to show changes, check that the update is shown on
> Master (which actually has these zones as slaves of VM1). Then I
> remove the master zone on VM1 with "rndc reconfig", nsupdate the
> catalog on Master.
Reproduced now on VM2 also. "rndc reconfig" was necessary to add an
option and an acl there. It wiped out all my catz member zones.
> What I have been doing to fix it, on VM1: rndc stop, remove the
> "catalog-zones" from the options{} section, start named again, then
> replace the "catalog-zones" option. At that point "rndc reconfig"
> adds all the member zones back.
I have not yet found a shortcut. If I leave named running,
subsequent reloads/reconfigs won't add in the catz member zones. I
think stop and restart without catalog-zones is the only way. Stop
and restart as-is does not add in the deleted catz member zones.
I suppose one "shortcut" would be to clear out all members from the
catalog zone, then nsupdate them back in. But that would only save a
few seconds and might cause more impact to services.
> It's very inconvenient. Am I perhaps doing something wrong, or have
> I overlooked something in the documentation?
Do you (ISC) want me to submit this to bugs.isc.org?
> Oh, and speaking of the documentation, I think some of what's in ARM
> chapter 4 should also be in ARM chapter 6. I usually expect to see
> the complete documentation in chapter 6, but all it has it the very
> brief syntax summary.
Another thing I should mention that surprised me was the lack of ";"
inside the catalog-zones option. I spoke to Witold, who told me the
syntax was modeled after response-policy. Fine, but note that
another multi-setting option, rate-limit, terminates subordinate
options semicolons. So I still think there is some inconsistency.
--
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: Resolve specified DNS name in a caching-only name server
On Sat, May 27, 2017 at 09:11:23AM +0800, Rui Mao wrote: > I've set up a caching-only name server. But I'd like to know if it > can do following things. > > > > 1. Resolve test.a.com to 192.168.1.1 > > 2. Still forward other *.a.com to outside DNS servers You can make a zone of however many labels you wish, but it's not perfect in ONLY affecting that one label. For example, if your zone was "a.test.example.com" you would also be authoritative for any additional labels, such as "this.is.a.test.example.com." Those wouldn't be resolved theough the regular authority for example.com (or whatever subzone might be delegated.) This is, however, a feature of dnsmasq. Simply list the name and address in /etc/hosts and that name [only] is served out via DNS to your local resolver clients. -- 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
Catalog "reconfig" calamity
I've started using the new catalog-zones feature, and whilst it has
been pretty nice on one new server, it has been painful to implement
on an existing one.
I run three nameservers for a small F/OSS project, slackbuilds.org.
One of these is a physical server machine, and the other two are
virtual machines. Formerly I had most master zones on one of the
VMs, with mostly slaves on the real machine. An old server is being
removed and replaced with a second VM at a different site.
To make the story easier to follow I'll use these names to refer to
the servers in question:
1. "Master", the physical machine, BIND 9.10
2. "VM1"[1] the existing VM, former master of most zones
3. "VM2"[2] the new virtual machine
Both VMs are running BIND 9.11.1, and all are on various versions of
Slackware Linux.
The plan is to migrate all masters to Master and to use catz to
provision the two VMs. As I said, this is all peachy and smooth on
VM2 (many thanks to Mukund and ISC for that.)
I have run into trouble on VM1. My procedure has been to update the
master zones to show changes, check that the update is shown on
Master (which actually has these zones as slaves of VM1). Then I
remove the master zone on VM1 with "rndc reconfig", nsupdate the
catalog on Master.
The first batch of these went well. The next batches bombed, because
"rndc reconfig" removes all the catz member zones! I looked in my
logs and saw gazillions of REFUSED queries for my catz zones.
The last batch of 3, I saw the catz member zones removed in the logs
after reconfig. Then I added the three to the catalog. Both VM1 and
VM2 got the notify, pulled the 3 new zones and started serving them.
But the previous zones were still gone from VM1.
What I have been doing to fix it, on VM1: rndc stop, remove the
"catalog-zones" from the options{} section, start named again, then
replace the "catalog-zones" option. At that point "rndc reconfig"
adds all the member zones back.
It's very inconvenient. Am I perhaps doing something wrong, or have
I overlooked something in the documentation?
Oh, and speaking of the documentation, I think some of what's in ARM
chapter 4 should also be in ARM chapter 6. I usually expect to see
the complete documentation in chapter 6, but all it has it the very
brief syntax summary.
Thanks again for this very nice feature! Even with the pain, I'm
certain it will be beneficial in the long run.
[1] An aside: that's the aircraft call sign (as represented in FAA
computers) for the US Marine Corps helicopter when carrying the
President (or for any USMC aircraft which might happen to
transport the President, for that matter.
[2] Similarly, this would be the designation of a USMC aircraft
transporting the Vice President.[3]
[3] And all this is terribly off-topic, sorry.
--
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: [Ext] Re: Redirect only second and third level domains
On Fri, Feb 24, 2017 at 02:05:54PM -0500, Warren Kumari wrote: > -- > I don't think the execution is relevant when it was obviously > a bad idea in the first place. > This is like putting rabid weasels in your pants, and later > expressing regret at having chosen those particular rabid > weasels and that pair of pants. >---maf LOL, perfect, thanks for that one. I've seen you use it before, but it's especially fitting in this thread. :) -- 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: Redirect only second and third level domains
> Il 23/02/2017 20:38, Warren Kumari ha scritto: > > What are you actually trying t odo? On Fri, Feb 24, 2017 at 09:42:17AM +0100, Andrea Gabellini wrote: > the server is a resolver for about 20K clients. My goal is to > supply a courtesy page if a domain is not found. For every domain. Ugh. You call it a courtesy, I call it ignorant and abusive. > A query for abc.example.com or example.com (and these do not > exist) has to receive the address of the courtesy web server. > > A query for xyz.abc.example.com (and this do not exists), have > to receive NXDOMAIN. > > This is a workaround for queries made to the dnsbl services like > spamhaus.org or mailspike.org, where the queries are of type > "4.3.2.1.zen.spamhaus.org". If the redirect is for all levels of > the domain, there is a response and the antispam system thinks > that this IP is in blacklist. No. A mail server needs clean DNS, no NXDOMAIN hijacking at all. Such as, if a user submits mail to somewhere@invalid.example, the MTA needs to know that "invalid.example" is NXDOMAIN. It's one thing, if you're trying to be "courteous" to ordinary web-only users; it is quite different when you are serving DNS to servers of various kinds. Your customers WILL be calling to complain. Perhaps you should offer a clean nameserver for business and static IP address customers? Inform them and advise them to change before you implement your "courteous" NXDOMAIN abuse? -- 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: trouble delegating a subdomain via NS record
On Thu, Feb 16, 2017 at 11:31:55AM -0500, John Ratliff wrote: > Im trying to delegate a subdomain to another BIND server, but > when I add the NS record, some of the records stop working. I was > hoping someone could help me figure out why. It's simple. > Here is a zone file that demonstrates the problem for example.com. > Its running on a CentOS 7 system with BIND 9.9.4. I saw the > problem originally on a Debian 8 server with BIND 9.9.5. > > $TTL 3600 > @ IN SOA ns1.example.com. hostmaster.example.com. ( > 2017021608 ; serial (mmdd##) > 7200; refresh secondary every 2 hours > 3600; retry secondary every hour thereafter > 1209600 ; expire w/o update in 14 days. > 3600 ) ; negative cache time of 1 hour > > IN NS ipa-test-client.example.com. The missing owner name on that line says, "Stick with the previous owner name for this record." > idm IN NS ipa1.example.com. You changed the owner name here. > IN MX 50 spamfw.example.com. The missing owner name on that line says, "Stick with the previous owner name for this record." Apparently you assumed that a missing owner name means "@", the current origin, but that is not so. > IN A 10.9.6.54 Likewise. > ipa-test-client IN A 10.9.6.117 > ipa1IN A 10.9.6.118 > > www IN CNAME example.com. > testIN A 10.9.6.222 > > If I use the zone like this, the MX and A records seem to stop > working (I get NXDOMAIN with dig). If I comment out the idm NS > line, it starts working again. Other records seem fine. The www and > test records resolve, but the CNAME for www does not fully resolve > into 10.9.6.117 when the idm NS delegation is in place. > > Is there a specific place I need to put the NS record for the idm > subdomain? Must it go at the end, or be placed after an $ORIGIN You probably don't want to set $ORIGIN. When a zone file is read, named sets an implicit $ORIGIN to the name of the zone as in the named.conf(5) zone statement. > declaration? I looked at a few guides on the internet, and they > didnt suggest anything like this. If you're going to use this format (missing owner names) you should keep all the same names together. I suggest always using an owner name on every line. It might not look as pretty, but it is definitely more grep-friendly. -- 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: Need of 2 $ORIGIN Directives
On Wed, Dec 21, 2016 at 01:00:22PM +, Ray Bellis wrote:
> On 21/12/2016 12:57, Harshith Mulky wrote:
>
> > So I wanted to understand some things about this Domain
> >
> > A. Why are there 2 $ORIGIN directives?
>
> Because someone thought they were being clever? :)
named itself does this in automatically-generated zone files, but
that's no reason for a human editor of zone files to do the same.
> > B. Can the above be replaced as below
>
> Yes, and you could even remove the trailing `atlanta.com.` on some
> of those records.
>
> > $ORIGIN atlanta.com.
Furthermore this too could be omitted, since:
zone "atlanta.com" IN { ...
a zone statement implicitly sets $ORIGIN to the name of the zone.
> > $TTL 86400 ; 1 day
> > @ IN SOA local.atlanta.com. master.atlanta.com. (
These names could be relative rather than absolute:
@ IN SOA local master (
> > 2001062522 ; serial
> > 21600 ; refresh (6 hours)
> > 3600 ; retry (1 hour)
> > 604800 ; expire (1 week)
> > 86400 ; minimum (1 day)
> > )
> > NS local.atlanta.com.
> > NS kabulvm8.atlanta.com.
and these, likewise.
NS local
NS kabulvm8
> > ;A Records
> > local A 127.0.0.1
> > kabulvm8A 10.54.49.43
--
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: internal/external view problem
On Wed, Dec 14, 2016 at 07:52:58PM +0100, Per olof Ljungmark wrote:
> I am facing a problem internal/external views, I will do my best
> to describe it:
>
> An internal host needs to nsupdate an external view using a key,
> but cannot because it is part of the internal ip range, at least
> that is what I think.
>
> The acutal use is for Letsencrypt certs.
>
> Is there a way do this witjh views or should I use another form
> of access control? The host sending the update needs to be part
> of "internals" to be able to lookup general names of course.
>
> I suppose I could use allow-query and others instead?
>
> acl internals {
> 192.168.1.0/24;
> };
>
> view "internal" {
This view has no match-clients setting. Therefore no query will
reach it. I suppose you wanted "match-clients { internals; };"
> zone "internal.example.com" {
> recursion yes;
> type slave;
> file "slave/db.internal.example.com";
> masters {
> 192.168.1.1;
> };
> };
> };
>
> view "external" {
> match-clients { any; };
Here is where they will go.
> recursion no;
> allow-transfer { slaves; };
> zone "example.com" {
> type master;
> file "dynamic/db.example.com";
> allow-update{
> key rndc-key;
Don't reuse your rndc key for zone updates. Make and use a different
key.
If that's NOT your rndc key, give it a better name so someone coming
in will know what it is for.
You would also add an exclusion in your "internals" acl for this
update key:
acl internals { !key update-key; 192.168.1.0/24; };
This way, any query ("query" being a generic term including
nsupdates) signed by the update-key is not routed to your
"internal" view.
> };
> };
> };
--
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: query time logging
On Fri, Dec 02, 2016 at 01:37:17PM +0100, Ivan Fabris wrote: > I'm runnig some analisys on my BIND instances, I'm interested in > find out how much time it takes every single query, but I' can't > find and option to show this information in the log > The dns is used by our customers and they ask for detailed reports > ( they'll never read ... :) Indeed. > It would be a little clumsy, and often meaningless, to subtract the > first line's timestamp from the last one so I hope there is a > way to show "query_exec_time=xxxns" somewhere > I'm running BIND 9.10 and 9.11-P1 in a Centos 7, with debug level > 99 There's a compile-time configure option, "--enable-querytrace", which might do what you want. It will also hurt performance and eat your system resources. You can try it, but it might not be worth it. You might also want to look at dnstap. NOTE: I have not tried either, so I don't know if they'll report what you want to see. -- 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: Blocking reverse lookup queries for private ips
On Tue, Nov 22, 2016 at 10:57:00AM +, Tony Finch wrote: > Sachin Patil <04sac...@gmail.com> wrote: > > > I want to return nxdomain for any private ip reverse lookup. > > BIND does this by default. Look for "built-in empty zones" in > https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html Please note however: empty zones change per minor version, so users of BIND 9.9 would need: https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.ch06.html and users of 9.10 would need: https://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html (Users of BIND 9.8 and earlier versions would need to contact their distributor for support.) -- 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: ip6tables with raw table(no conntrack) drop fragmented packet
On Fri, Sep 30, 2016 at 11:55:18PM -0400, Larry Larson wrote: > I've followed instructions in this BIND Knowledge base article and > installed ip6tables on my DNS server, using raw table with no > conntrack for DNS: > https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html This is mostly for authoritative servers which must be open to queries from anywhere. Perhaps this is not a real issue, as it sounds like you might be setting up a recursive server? Of course, it CAN be a problem for recursive-only servers too; it just depends how many users and concurrent queries you need to support. If your userbase can flood your conntrack table, you need this. > But for IPv6 it drops fragmented packets, for example this query > fails once the ip6table is on: > dig +dnssec isc.org any @2001:500:60::30 Can you show us how you found out that it was affecting fragments? Is this query falling back to TCP? Do you have a pcap? > Everything works great for IPv4 with similar rules, can someone > help shed some light on what might be wrong: > > # Firewall configuration written by system-config-firewall A minor issue, the NOTRACK target is deprecated by CT with the --notrack option. (That's not the problem, however.) We can test things with a few TRACE rules. Let's add rules as follows: > *raw > :PREROUTING ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] -A PREROUTING -s 2001:500:60::30 -j TRACE -A PREROUTING -d 2001:500:60::30 -j TRACE > -A PREROUTING -p udp -m udp --dport 53 -j NOTRACK > -A PREROUTING -p udp -m udp --sport 53 -j NOTRACK -A OUTPUT -s 2001:500:60::30 -j TRACE -A OUTPUT -d 2001:500:60::30 -j TRACE > -A OUTPUT -p udp -m udp --dport 53 -j NOTRACK > -A OUTPUT -p udp -m udp --sport 53 -j NOTRACK > COMMIT > *filter > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED,UNTRACKED -j ACCEPT > -A INPUT -p ipv6-icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > #tcp dns > -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 53 -j ACCEPT > -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --sport 53 -j ACCEPT > -A INPUT -j REJECT --reject-with icmp6-adm-prohibited > -A FORWARD -j REJECT --reject-with icmp6-adm-prohibited > COMMIT For TRACE rules to work the LOG module must be loaded. A quick, temporary way to do that: # ip6tables -A INPUT -i bogus -j LOG # ip6tables -D INPUT -i bogus -j LOG (That adds and then removes a no-op rule using the LOG target.) Then repeat your test, > dig +dnssec isc.org any @2001:500:60::30 on this machine. Then show us "ip6tables-save -c" along with all the "TRACE" lines from dmesg. A quick way which should work for that: # dmesg | grep TRACE After the test, you might want to disable those TRACE rules, in case you had other business with 2001:500:60::30 -- they can get very noisy, very quickly. Coincidentally, I happen to be working on this very issue, with a different approach: shortened TTL for conntrack entries for UDP DNS. It came up on the Netfilter mailing list recently. I'll be sure to post here when that (a documentation patch) is completed. -- 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: broken trust chain on forwarder
On Fri, Sep 30, 2016 at 01:32:29PM -0400, jratl...@bluemarble.net wrote:
> On Fri, 30 Sep 2016 11:37:39 -0500, /dev/rob0 <r...@gmx.co.uk> wrote:
> >>
> >> This seems to indicate that the servers at 10.21.0.100 and 101
> >> are telling me that stc.corp domain is DNSSEC enabled. However,
> >> the new server fails to find any DS or RRSIG records, so
> >> validating this claim is not possible. Is this interpretation
> >> accurate? Are the errors I'm seeing here the result of a
> >> misconfigured DNS server at our HQ?
> >
> > Not quite, no. The 10.21.0.10[01] servers are giving you
> > insecure answers which conflict with those you have already
> > gotten from the root, which say there is no "corp." TLD.
> >
> >> I've seen on the internet people suggest disabling DNSSEC
> >> validation. That seems to be an extreme solution to this
> >> problem. It works, but my understanding is that this would
> >> disable DNSSEC validation globally, not just for a single zone.
> >
> > That's correct, and it's the only workaround I know of, other
> > than going to BIND 9.11 and having a cron job to set a negative
> > trust anchor ("rndc nta") for stc.corp.
> >
> > Note that this usage of NTA is undocumented and not recommended;
> > NTAs are intended to be temporary.
> >
> >> The HQ DNS servers at 10.21.0.100 and 101 are Microsoft DNS
> >> servers over which I have no control, if that information is
> >> relevant.
> >
> > It is. If you could have at least one of those allow you to
> > transfer the stc.corp zone, you could have a slave zone, which
> > would have been another possible workaround.
> >
> > As a slave zone, your server would have authoritative answers,
> > and thus no need to go to the root.
>
> What I'm hearing is that the real problem is that stc.corp, not
> being a valid TLD, cannot be verified back to the root using
> DNSSEC. So, the HQ DNS server is not necessarily misconfigured, but
> there is no possibility of doing any configuration involving DNSSEC
> validation including this zone, because the chain of trust cannot
> ever be verified.
Yes. As Warren pointed out (and I meant to, forgot) the idea of
using a make-believe top-level domain is not a good one. A name like
"corp" is sure to attract bidders, and while I can resist money, can
ICANN? :)
> So, my options are.
>
> 1) Disable DNSSEC validation. Works, but is global, at least in my
> version of BIND.
> 2) Update BIND to 9.11 and use negative trust anchors, which is not
> recommended.
Let me clarify that: it goes against the spirit of NTA as intended.
It will work, unless/until the cron job fails to renew the NTA
eventually, but that will be a quick and easy fix, if you are aware.
> 3) Change from a forwarder to a slave and thereby become
> authoritative and no longer have any need of DNSSEC validation on
> this zone.
Did you try with stub or static-stub?
> On Fri, 30 Sep 2016 12:57:02 -0400, Warren Kumari <war...@kumari.net>
> wrote:
> > What about creating and installing a local trust anchor for
> > .Corp? Also, im assuming that you already know that using a local
> > / non-delegated TLD is a really bad idea. You should strongly
> > consider moving your namespace under E.g companyname.com [2].See
> > the whole set of discussions on name collisions, home/Corp/mail,
> > the inability to get TLS certificates, etc.
> > W(Apologies for terseness, about to go into dr appt).
Thanks Warren, good luck at the doc.
> I don't know what a local trust anchor is. I will look into this.
I've been spoiled by the BIND 9.8+ validation features, so TBH I
haven't done much with manual trust anchors. I took Alan's class in
2013, and we did a trust anchor there, but it replaced, rather than
augmented, the real root key.
> Yeah, .corp is a bad idea, but unfortunately for me, it is not
> within my control.
You might want to mention the ICANN money grab to them, if you do
have access to Those Who Decided.
--
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: Multiple IPs Associated With A Single Name
On Fri, Sep 30, 2016 at 10:22:35AM -0500, Tim Daneliuk wrote: > In my particular case, I am trying to figure out a way to redirect > gethostbyname() calls to the resolver of my choice so that existing > code will run without change. The problem is that I need to do > this without root or sudo access to the machines in question, and > this is increasingly looking impossible. AFAICS, yes, you must have root. Even if your libc resolver supports using a different port, you would have to be root to change /etc/resolv.conf. Another root trick to use could be to redirect 127.0.0.1:53 (both TCP and UDP) to :1035 (or other such non-privileged port as needed.) -- 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: broken trust chain on forwarder
On Fri, Sep 30, 2016 at 12:04:33PM -0400, John Ratliff wrote:
> I am building a new recursive DNS server. I have it set to forward
> records for a single zone to our HQ DNS servers. When I try to
> resolve a record, I get errors like this:
>
> Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> @0x7fb51810b8f0: stc.corp SOA: got insecure response; parent
> indicates it should be secure
> Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG)
> resolving 'inelhqnagios.stc.corp/DS/IN': 10.21.0.101#53
> Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> @0x7fb520545fe0: stc.corp SOA: got insecure response; parent
> indicates it should be secure
> Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid RRSIG)
> resolving 'inelhqnagios.stc.corp/DS/IN': 10.21.0.100#53
> Sep 30 11:25:39 bltn-dns-04 named[2012]: error (no valid DS)
> resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.100#53
> Sep 30 11:25:39 bltn-dns-04 named[2012]: validating
> @0x7fb51810ac60: inelhqnagios.stc.corp A: bad cache hit
> (inelhqnagios.stc.corp/DS)
> Sep 30 11:25:39 bltn-dns-04 named[2012]: error (broken trust chain)
> resolving 'inelhqnagios.stc.corp/A/IN': 10.21.0.101#53
>
> This seems to indicate that the servers at 10.21.0.100 and 101 are
> telling me that stc.corp domain is DNSSEC enabled. However, the new
> server fails to find any DS or RRSIG records, so validating this
> claim is not possible. Is this interpretation accurate? Are the
> errors I'm seeing here the result of a misconfigured DNS server at
> our HQ?
Not quite, no. The 10.21.0.10[01] servers are giving you insecure
answers which conflict with those you have already gotten from the
root, which say there is no "corp." TLD.
> I've seen on the internet people suggest disabling DNSSEC
> validation. That seems to be an extreme solution to this problem.
> It works, but my understanding is that this would disable DNSSEC
> validation globally, not just for a single zone.
That's correct, and it's the only workaround I know of, other than
going to BIND 9.11 and having a cron job to set a negative trust
anchor ("rndc nta") for stc.corp.
Note that this usage of NTA is undocumented and not recommended; NTAs
are intended to be temporary.
> The HQ DNS servers at 10.21.0.100 and 101 are Microsoft DNS servers
> over which I have no control, if that information is relevant.
It is. If you could have at least one of those allow you to transfer
the stc.corp zone, you could have a slave zone, which would have been
another possible workaround.
As a slave zone, your server would have authoritative answers, and
thus no need to go to the root.
> I am running bind9 9.9.5 on Debian 8 with this single zone defined
> in an otherwise stock debian bind9 configuration. I can post the
> remainder of my config if it would be of use.
>
> zone "stc.corp" IN {
> type forward;
> forwarders { 10.21.0.100; 10.21.0.101; };
> forward only;
> };
Oh, another thing you can try; offhand I don't know if it will work,
but try a zone of type "stub" or "static-stub".
--
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: root.hind or named.hint file update
On Fri, Sep 23, 2016 at 02:31:51PM +0200, Matus UHLAR - fantomas wrote: > >Pol Hallen wrote: > >> > >>is it recommend put a cron script for auto-update root.hind > >>and named.hint db? > > On 23.09.16 12:54, Tony Finch wrote: > >No, it's best not to have a hints file and just use the one > >built in to BIND. I agree. > i would not say that... it's better to use builtin hints file > than having outdated hints file. > > But if someone does care about hints file, it's better to have > current version, when the builtin one is older. Seem that all of Pol's posts lately are about trying to fix problems which do not exist, and this one is solidly there. The fact is, outdated hints (whatever the source, built-in or from hints file) will not yet cause a problem. You could look back to the 1990s, find a hint file from then, use that now, and you WILL find active root servers. Once you find the root, the hints file is no longer used. When your cached root NS RRset expires, named will go to the known root servers to refresh that NS RRset. In theory, someone could put up a counterfeit root nameserver on an IP address formerly used by a real root server, but in practice I doubt this will happen. Furthermore, DNSSEC validation defeats an attack of that nature. Pol, if you are interested in knowing how named uses hints, there's a fairly recent article on the ISC KB which goes into detail.[1] My personal recommendation, however, is that if you wish to learn more about how DNS works, consult a book such as the Cricket book. [1] Sorry, I am too lazy this morning to look it up for you. -- 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: replicate a whole master
On Mon, Sep 19, 2016 at 03:51:17PM +0200, Pol Hallen wrote: > dig yahoo.it @192.168.1.212 > > query is 38ms, second query is 1msec > > Can I replicate a whole internet primary dns to have on my bind in > local network all domains name updated? "Internet primary dns", are you referring to the .it top-level domain, or the yahoo.it. zone? In either case the answer is the same: if you can find a server which allows axfr/ixfr, yes, you can configure the zone as a slave zone. One caveat: because you are not one of the published NS for that zone, you are not going to receive notifies when the zone data is changed. You can ask the zone owner to add you to the also-notify list, but in neither case are you likely to get that. > Is 38ms an acceptable results? I checked from my well-connected server in Alabama USA, and I got 372ms, almost ten times your result. Of course that query was probably trans-Atlantic, so that adds a bit of latency. If you're thinking that you can do this replication to improve DNS performance, you're right, it will do that. But it certainly will not scale (if it's even possible to get axfr/ixfr), and it won't handle modern CDN systems properly. -- 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: High performance DNS server configuration?
On Thu, Sep 15, 2016 at 02:20:16PM +0300, Pekka Jalonen wrote: > I'm looking solution for very high performance DNS server. > > Background information; > We are running centos-release-6-8.el6.centos.12.3.x86_64 > > Hardware is Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz with 32 GB > memory and SSD disks (with raid controller). > > We have local bind running at same box (bind, caching) with default > configuration. Ask on a CentOS list if you don't wish to provide the configuration in use. We don't all know what "default" means there. > Server is mail server with ~+150 K users. > > Problem is procmail + postfix with rbl's (zen.spamhaus.org and > others). Hmm, procmail, why? Is that doing DNS lookups? Sounds ugly. Are you using postscreen(8)? If not, why not? I would strongly suggest upgrading to a recent Postfix version (the "ghettoforge" RPM repo might be an easy way to do this), then implement postscreen. > Really big problem are spam botnet's and some day we can get over > 5-6 million messages per day or even more. > > Procmail/postfix is doing every check per msg at localdns (localdns > => rbl's) server and average check time is 1-2 sec per message and > it's too much. > > We are getting very fancy error messages etc ... > named[10008]: error (connection refused) resolving > 'ns1.actcorp.co.in/A/IN': 162.251.82.251#53 > named[10008]: error (connection refused) resolving > 'www.sleekgroup.co.uk/A/IN': 104.155.71.90#53 If your queries are refused, you can't fix that with tweaks to your named.conf(5). For some reason the destination server has been configured not to allow your queries. That condition will still exist after any changes you make to your system. > named[10008]: error (unexpected RCODE SERVFAIL) resolving > 'sunbatheda.megabulkmessage223.com/A/IN': 8.8.8.8#53 ^^^ This suggests you are using forwarders. That certainly could be a problem for DNSBL usage, as many DNSBL providers do limiting on queries. Remove the forwarders. > named[10008]: error (host unreachable) resolving > '40.17.107.150.bl.emailbasura.org/A/IN': 80.38.217.151#53 This is similar to the refused errors in that the condition is external; if you can't reach that host now, named.conf changes cannot make that host reachable. > named[10008]: validating @0x7ff45c04aae0: gansend4.com A: no valid > signature found This suggests you have enabled DNSSEC validation. Nothing wrong with that, but understand what it means: when a signature for a signed zone fails to verify (or is missing) you get a SERVFAIL. > ... it's slowing down system of course. The slow system is not demonstrated to point to named. > Loads are very high at server when botnets are attacking average is > about 500 or even more. > > Does anyone have ideas how recude server loads because bind is > problem... If that is so, how did you determine that? How could we know? > Thank you for answers or ideas. -- 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: DNS views and zone transfers
On Wed, Sep 07, 2016 at 11:48:54AM -0400, Bob Harold wrote:
> On Wed, Sep 7, 2016 at 11:37 AM, project722 <project...@gmail.com> wrote:
>
> > Thanks Bob, I will look into this. Do you know if the forwarders
> > feature is supported in Bind 9.8.2?
> >
> Yes, forwarders is an old and stable feature.
>
> ("in-view" is new and experimental)
"New" is fair to say, if you call BIND 9.10 "new". OTOH it is
unfair/wrong to call it "experimental". 9.10 has been in stable
release form for quite some time now, and there have been no problems
with the in-view zone feature, AFAIK.
> > On Wed, Sep 7, 2016 at 9:38 AM, Bob Harold <rharo...@umich.edu> wrote:
> >
> >>
> >> On Tue, Sep 6, 2016 at 5:23 PM, project722 <project...@gmail.com> wrote:
snip
> >> Here is the basic structure:
> >>
> >> view "internal" {
> >> match-clients {
> >> // this list must not match 127.0.0.1
> >> !key "external"; // use this key to test the external view
> >> 10.0.0.0/8;
> >> key "internal"; // use this key to test the internal view
> >> };
> >> zone "itd.umich.edu" {// this zone is different in the two views
> >> type master;
> >> file "internal/itd.umich.edu";
> >> };
> >> forwarders {
> >> // forward to external view
> >> 127.0.0.1;
I have never thought to try this, but I would not expect it to work.
Does it?
> >> };
> >> forward only;// optional
> >> };
> >> view "external" {
> >> match-clients {
> >> // this list must match 127.0.0.1
> >> any;
> >> };
> >> zone "itd.umich.edu" {// this zone is different in the two views
> >> type master;
> >> file "external/itd.umich.edu";
> >> };
> >> zone "10.in-addr.arpa" { // all other zones will be seen by everyone
> >> type master;
> >> file "external/arpa.in-addr.10";
> >> };
> >> zone "umich.edu" {
> >> type master;
> >> file "external/com.umich";
> >> };
> >> };
--
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: Forwarding via different external networks
On Sat, Aug 27, 2016 at 02:32:42PM -0400, Paul Kosinski wrote: > Currently, I forward all outbound DNS via the DSL to the ISP's > DNS servers. (I have more confidence in the DSL provider not > interfering with DNS than in Comcast.) FWIW, it has been many years since I have dealt with Comcast as a customer, but I can tell you for sure that Comcast employs some very clueful DNS experts. > However, there have been a couple of cases recently when the DSL > was not getting beyond their gateway router, which meant that DNS > would fail, causing much HTTP(S) to fail even though the cable > network was working quite nicely. > > So my question is, is it possible to configure my forwarding BIND > to have a primary and *secondary* path for sending out DNS queries? Your better bet is surely to dump the forwarders and to do your own recursion. -- 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: Allowable reverse mapping zone file names
On Sat, Aug 27, 2016 at 10:47:36AM -0500, Tom Browder wrote: > I do not control 3-octet networks but need reverse mapping for my > mail server. Discuss that with your ISP or netblock owner. > Two questions: > > 1. Where is the doc that completely describes the allowable reverse > mapping zone file names? There is no limit within BIND on what you name a zone file. I suspect you might be wondering about the names of in-addr.arpa. *zones* instead? To use an example, 127.0.0.2, a resolver would request a PTR record named "2.0.0.127.in-addr.arpa". That is the reversed octets of the dotted-quad IPv4 address with ".in-addr.arpa" appended. A zone could exist at any of these names: * 127.in-addr.arpa * 0.127.in-addr.arpa * 0.0.127.in-addr.arpa * 2.0.0.127.in-addr.arpa (See also RFC 2317 for "classless" reverse DNS delegation, but no, DO NOT read that: I only mention it for completeness, as we have pedantic posters on this list ... myself included. ;) ) > 2. When running my own authoritative name servers, do I need > reverse mapping for anything other than my single mail server? You only need an in-addr.arpa zone IF that zone has been delegated to your nameserver[s] by a netblock owner or by your RIR (such as RIPE for Europe, ARIN for North America, et c.) If the zone has not been delegated to you, ^^ go back to the top and talk to your ISP or netblock owner. If you're still confused, tell us what your IP address is and we might be able to tell you who to contact. -- 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: forward first and fallback not working
On Wed, Aug 24, 2016 at 05:28:55PM +0200, Marco Felettigh wrote: > The dns resolution with 8.8.8.8 works fine with "forward first" if > 8.8.8.8 is working but for testing i blocked with an intermediate > firewall the dns requests to the forwarder and two things happened > (the second one is bad). > > 1) If the firewall reset the connection to 8.8.8.8 bind fallbacks >on its root servers and this is good > > 2) If the firewall drop the connection to 8.8.8.8 bind does NOT > this fallback on its root servers and this is a bad thing cause > in this way i was testing a network outage for my forwarder. > > below my config I am not sure this is a BIND issue. Try this with a longer timeout set in your resolver ... > Hi attach also che config > > /etc/resolv.conf > search domain.dom > nameserver 127.0.0.1 options timeout=20 Try similar settings on other clients. My glibc (GNU/Linux) resolver says the default timeout is 5 seconds. I'm not sure about named, but I think its timeout is greater than that. So named is waiting for its own timeout before attempting recursion. By the time recursion is complete, the client has long since given up. > named.conf snip If anything needs to change on the BIND side of this, perhaps it would be the documentation of "forward first", to note that this feature won't work with most standard resolver clients. I would further suggest that this fallback isn't a very good idea anyway; you'll probably be better off just doing the recursion without forwarders in the picture. -- 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 9 API & GUI
On Mon, Jul 25, 2016 at 03:36:06PM -0600, Kirk wrote: > I have been looking for a way to provide both an API and a GUI > interface for my multi-master/slave BIND infrastructure. > > There are obviously many GUI options, but finding a solution that > will allow for external programs to add/change/delete records > (API), See the nsupdate(1) manual; also RFC 2136 and the BIND 9 ARM chapter 4. > and allow administrators to manually make the same kinds of changes > (GUI) without each process interfering with each other has proven > more difficult than I expected. Features which would work well behind a GUI frontend exist, and more are coming in BIND 9.11. See the rndc(8) manual and the various commands it has. The rndc *zone commands (addzone, delzone, modzone) will improve the experience of running a master/slave group of nameservers, as will the "catalog zones" feature which is in planning stages. > This seems like it would be a common need, and I can't be the only > one in this "bind". > > Has anyone else solved this problem? Dynamic update of zone data was solved with RFC2136, April 1997 (over 19 years ago!) Various commercial DNS appliance vendors have implemented GUI frontends, but those are now within reach of mere mortals. -- 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: Questions on bind-chroot
On Mon, Jun 13, 2016 at 04:04:06PM +0100, Tony Finch wrote: > Harshith Mulky <harshith.mu...@outlook.com> wrote: > > > Is it necessary for named.conf in the chroot path and /etc path > > to be same > > If they aren't the same, at some point in the future you or your > colleagues are going to get very confused about which one is the > right one. > > > I have 2 different named.conf in both the paths and when I am > > running the, service named restart, I see the named service > > starting from the chroot path. Is that correct? > > There isn't much standardization of BIND init scripts. Some of them > try to keep in-chroot and out-of-chroot configuration in sync, some > don't, maybe depending on how the script is configured. So I can't > give you a direct answer; you should read your init script > carefully. Also the OP should consult the distributor's documentation for their BIND configuration. BIND from upstream comes unconfigured, that is, without anything like "bind-chroot". In addition, as suggested upthread, it's not possible to answer any questions which should have gone to the distributor if we don't know the distro & version. -- 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: ISC considering a change to the BIND open source license
On Tue, Jun 14, 2016 at 08:06:55PM +, Evan Hunt wrote: > On Tue, Jun 14, 2016 at 12:38:14PM -0700, Ted Mittelstaedt wrote: > > In reality, there IS no "middle ground" If you truly believe a > > piece of software SHOULD be freely licensed, then that includes > > the idea that commercial entities can use it as they see fit. > On a personal level, I actually agree with you, and I find the idea > of relicensing somewhat regrettable. It's not that I'm against the > GPL, I think software creators should be able to share their work > on whatever terms they like, but *personally* I like giving my > stuff away with as few encumbrances as possible. It's > disappointing to me to add any burden to it at all. I do like > eating, though, and I won't be able to fix as many bugs if I have > to stop doing that. :/ Or start eating bugs? ;) /me stares at a lightning bug going by the window (a light meal) -- 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: Reverse Zone CIDR
On Wed, May 25, 2016 at 12:06:40PM +0100, Tony Finch wrote: > Jonathan Del Campo <j...@mikrosimage.eu> wrote: > > > > So if I have to create two /24 reverse zones for my case, I will, > > but I was hopping a smarter solution. > > Oh, I had a brainfart, I read /23 as /25 :-) I figured that was what you were thinking. :) > Yes, two /24s is the best solution. > > For smarter solutions, see the rfc2317bis I-D, though they are > usually not an option, depending on how the parent /16 zone is run. In this case, being a netblock from RFC 1918, another choice is to actually run that /16 zone ... 168.192.in-addr.arpa. -- 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: Forward zone not working
On Mon, May 16, 2016 at 07:30:30PM +0200, MegaBrutal wrote:
> zone "y.y.y.y.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" {
> type forward;
> forward only;
> forwarders { ::; }; // IPv6 address of AllKnowingDNS.
> };
>
> Where x substitutes digits of my /48, y substitutes digits of my
> /64, and z substitutes digits of the AllKnowingDNS IPv6 address.
>
> It simply doesn't work. In query logs, I see BIND treats requests
> for the zone as if they were requests for recursion, thus rejects
> them appropriately. DiG backs this up with "status: REFUSED". It
> doesn't seem like if BIND does any effort in forwarding the zone,
> it just treats it as non-authoritative, which would need recursion,
> and of course recursion is very properly disabled. It's like the
> zone entry weren't even there.
>
> Does anyone have any insights or suggestions?
A query will only be forwarded if RD is set and recursion is
permitted for that client, as you have already discovered.
Perhaps a zone of type "stub" or "static-stub" would do the job?
--
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: Maintain task frequency
On Tue, May 10, 2016 at 10:09:09AM -0500, Jorge Alberto Martínez Melo wrote: > It seems that my maintain proposed tasks are unnecessary. > Furthermore occasional backups and updates, in your opinion what > are frequent necessary maintain tasks for a cache dns server. The answer depends on the importance of these servers to your company's mission. As you seem to be from an ISP, I'll assume they're critical, that you'd be getting phone calls from paying customers within minutes of an outage. First I'd say you need monitoring. Don't wait for the phone calls, which are going to have to be filtered through first-level support before the DNS team is alerted. Your NOC needs to know immediately when there is a crash or other outage. (For that matter, so does first-level support; they need to be prepared for the question and to sound like they know what they're talking about.) Second, I'd strongly recommend diversity. As much as we all love BIND9 here, don't put all your resolver eggs in that basket (please forgive the idiomatic expression, but I think you can figure out the meaning.) Consider pdns-recursor and unbound, for example, to augment your BIND resolver farm. Third, I'd use an anycast arrangement to keep things simple for the user and to provide a kind of failover. One or two IP addresses can be answered by any number of nameservers. Fourth, consider a BIND ASN subscription agreement. This way you will be alerted prior to public disclosure of any BIND security issue, and you'll get the patched code in advance of public release. (Disclaimer: I am not affiliated with ISC.) Four-and-a-half: even if you choose not to go with the ASN contract, stay alert and ready to patch when an issue is announced. Know how to build from source for your platform and how to quickly deploy upgrades across your farm. Automation tools such as ansible or salt can help here. Fifth: while it generally doesn't hurt to serve a few authoritative zones to your users through the resolvers, the resolvers should NOT be published as NS for any zone, and they should NOT be reachable from outside your networks. In fact a little internal isolation might be useful too: a division of your networks into chunks, each with its own set of resolvers, and blocked from other chunks. See also the ISC KB article on best practices for resolvers. I probably missed something, but that's a good start. -- 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: Maintain task frequency
On Mon, May 09, 2016 at 05:54:22PM -0500, Jorge Alberto Martínez Melo wrote: > I am preparing some scripts to maintain some cache dns servers and > I am thinking about the most appropriate frequency of these tasks: > - to generate the root hints file (root cache). Never. You'll get new root hints every time you upgrade, if the hints have in fact changed. Even if you don't upgrade, it doesn't matter. Having a wrong address in hints means that you might try contacting a bad IP address at startup. Once you have found an actual root server you'll never go back to the hints. And you can find actual root servers listed in hints files which date back far before the BIND 9 project's existence. For ease of management you might want to remove the "zone '.'" statements from your recursive resolvers. That way you'll only use the built-in hints, and every time you upgrade, such as for the latest security issue, you've got the new hints. There's a recent article at the ISC KB about root hints, you might want to read that also. It should be easy to find at https://kb.isc.org/ , searching for "root hints". > - to clear the cache with rndc flush Oh my! Never, unless you have some good reason to do it. Why do you think that should be a scheduled task? > - to generate the stats file with rndc stat Never. See the statistics-channels functionality, which is far superior to the "rndc stats" output, in real time as needed, and designed to be easily parsed by automated tools. -- 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: Nsupdate usage scenario
On Wed, May 04, 2016 at 03:17:38PM -0400, Paul Kosinski wrote: > Interesting idea -- it never occurred to me that I could have > separate zone files for sub-domains. Every zone is a subzone of its parent zone. > So, if I had a tiny zone file for "dynamic.example.com" alone, and > a bigger zone file for all the other stuff for "example.com", could > I be *sure* that nsupdate would *only* modify the tiny file, and > not mess with the bigger, main file? > > Or would I also have to put a ZONE statement as the first line of > the nsupdate data stream specifying "dynamic.example.com" as the > zone to be updated? (And would that *guarantee* the main file was > not changed?) This is a bigger can of worms than you think. I did it with my own dynamic zone some years back, now wishing to flatten it back into the parent zone (because they are both dynamic now.) * You have to delegate the [sub]zone to a set of nameservers * You have to configure those nameservers to serve that [sub]zone The NS for your subzone can be, but need not be, the same as the ones serving your parent zone. Choose one to be master. Put that name in the SOA MNAME field for the subzone. (The MNAME is used by nsupdate in choosing where to send an update. It's not essential because you can also use a "server" line in your nsupdate input.) Note that on the master you need an allow-update or update-policy in your zone statement. My personal recommendation: get over the idea of looking at zone files; use "dig axfr example.com. | less". Let named manage and serve the DNS data as it will. Comments can be included as TXT records if you like. -- 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: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Sun, Apr 24, 2016 at 12:04:15PM -0700, jaso...@mail-central.com wrote: > I'm doing an nsupdate to a remote server from my desktop > > cat nsupdate.txt >server ns01.example.com >debug yes >zone example.net. >update add test.example.net. 500 in TXT "TEST STRING" >show >send > > nsupdate -k ./jason-key ./nsupdate.txt > > On the nameserver, logs show what appears to be 'success', > > Apr 24 11:47:07 ns01 named[23053]: 24-Apr-2016 11:47:07.949 > update-security: info: client 10.0.0.17#4218/key jason-key: view internal: > signer "jason-key" approved > Apr 24 11:47:08 ns01 named[23053]: 24-Apr-2016 11:47:07.949 update: > info: client 10.0.0.17#4218/key jason-key: view internal: updating zone > 'example.net/IN': adding an RR at 'test.example.net' TXT "TEST STRING" > > checking with dig, it's NOT in 'TXT' where I expected it > > dig TXT example.net +short > (empty) As Anand pointed out, you were wrong to expect it there. That's a part of the mystery solved. > instead it's in 'AXFR' > > dig AXFR example.net > > ; <<>> DiG 9.10.3-P4 <<>> AXFR example.net > ;; global options: +cmd > example.net. 5 IN SOA > ns01.example.com. ns-admin.example.com. 1461435298 7200 1800 604800 5 SOA serial is 1461435298 here ... > example.net. 5 IN NS > ns01.example.com. > example.net. 5 IN A 127.0.0.1 > test.example.net. 500 IN TXT "TEST STRING" > example.net. 5 IN SOA > ns01.example.com. ns-admin.example.com. 1461435298 7200 1800 604800 5 > ;; Query time: 1 msec > ;; SERVER: 10.0.0.53#53(10.0.0.53) > ;; WHEN: Sun Apr 24 11:48:58 PDT 2016 > ;; XFR size: 5 records (messages 1, bytes 213) > > The journal HAS been modified > > cd > grep -rlni acme . > ./namedb/master/internal.example.net.zone.jnl > > After a bind restart, which iiuc is supposed to flush the journal to files, Yes it will, but this is not necessary. > systemctl stop named.service > systemctl start named.service (My guess is that the problem occurs here. What did systemctl do?) > checking with dig, the update's missing > > dig AXFR example.net > > ; <<>> DiG 9.10.3-P4 <<>> AXFR example.net > ;; global options: +cmd > example.net. 5 IN SOA > ns01.example.com. ns-admin.example.com. 1461435297 7200 1800 604800 5 1461435298 has been reduced to 1461435297, as if the update had never happened. > example.net. 5 IN NS > ns01.example.com. > example.net. 5 IN A 127.0.0.1 > example.net. 5 IN SOA > ns01.example.com. ns-admin.example.com. 1461435297 7200 1800 604800 5 Another problem with this zone is that the single NS host "ns01.example.com." has no A/ records. This zone would not pass named-checkzone, which interestingly, is the same code which named itself uses when initially loading a zone. > ;; Query time: 2829 msec > ;; SERVER: 10.0.0.53#53(10.0.0.53) > ;; WHEN: Sun Apr 24 11:52:32 PDT 2016 > ;; XFR size: 4 records (messages 1, bytes 178) > > cd > grep -rlni acme . > (empty) > > What am I failing to do to make this update persistent across flush/restart, > as intended? What is deleting your journal? It's not named doing that. Why was the journal not written to the zone file on exit? That's something named DOES do. The smoking gun is in the hand of systemctl ... -- 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: Recursive bind becomes unresponsive with high load
On Fri, Apr 01, 2016 at 09:48:01PM +, Mike Mitchell wrote: > Have you checked the Kernel's connection tracking statistics? > Here's a link: > https://kb.isc.org/article/AA-01183/0/Linux-connection-tracking-and-DNS.html > > I've had to increase some network parameters on our busy > nameservers. I put the following in /etc/sysctl.conf Did you try disabling connection tracking for UDP DNS, as the referenced article suggests? > net.netfilter.nf_conntrack_udp_timeout_stream = 45 > net.nf_conntrack_max = 50 > net.ipv4.neigh.default.gc_thresh1 = 512 > net.ipv4.neigh.default.gc_thresh2 = 1024 > net.ipv4.neigh.default.gc_thresh3 = 2048 > net.ipv4.tcp_max_syn_backlog = 4096 > net.ipv4.tcp_fin_timeout = 30 > net.ipv4.tcp_tw_recycle = 1 -- 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: *Reminder of the* L-Root IPv6 address renumbering
On Mon, Mar 21, 2016 at 02:26:45PM -0400, Anne Bennett wrote: > John Bond <b...@johnbond.org> writes: > > > This is reminder that there is a scheduled change to the IPv6 > > addresses for the L-Root server, that will take effect on > > March 23, 2016. > > > > The new IP addresses for the L.ROOT-SERVERS.NET will be: > > > > 199.7.83.42 > > 2001:500:9f::42 > > ftp://ftp.internic.net/domain/named.cache is still dated > Feb 17 and still shows 2001:500:3::42 for L's IPv6 address. > Is there any intention to update that? Yes, it was stated upthread: > New hints files will be available at the following URLs once > the change has been formally executed on March 23, 2016: > > * http://www.internic.net/domain/named.root > * http://www.internic.net/domain/named.cache -- 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: about NS server authorize
On Mon, Mar 21, 2016 at 07:44:51PM +0800, supp...@cloudwebdns.com wrote: > Hi, > > ns5.cloudwebdns.com > ns6.cloudwebdns.com > > For these two nameservers (they are the native BIND 9), we can use > them to resolve the other domains like .com/.net/.org/.info etc. > > But when we try to setup a .me domain to be resolved by them, from > the registrar's control panel, it gets failed, saying name server > not authorized. > > This is may be something wrong around EPP and host object. I don't know what this means. It is not a BIND question in any case. > Can you help setup the host object with these two nameservers into > .me's registry? No, Matus was right. It sounds like you need to go to the .me registry for support. If they have not "authorized" your servers to be authoritative for .me zones, only they can help you. -- 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: root hints operation
On Mon, Nov 16, 2015 at 06:37:36PM -0700, Grant Taylor wrote: > In light of the upcoming H-root server changing addresses I wanted > to confirm how BIND uses root hints. > > It's my understanding that BIND has a compiled in version of the > root hints -and- a root hints file that can easily be updated. You either specify a hints file to use, or use the compiled-in root hints. > This information is used to prime named as it starts up in such as > it takes an IP for one of the root servers and attempts a to query > to update the root hint server name to IP mappings. I believe that > named will cycle through all of the IPs in the root hints file > until it finds a server that it can query and update all of the > root server names / IPs in memory. From and then continues running > with that updated information. > > As such, I think BIND will continue operating with little, if any, > ill effect if people don't update their root hints file > immediately. (Though ideally people should update.) Since the beginning of DNS, there has not been enough change to root hints so as to cause operational problems. > Will someone take a moment and confirm, or correct, my > understanding of how root hints work in BIND? I think this should answer your questions: https://www.isc.org/blogs/h-root-will-change-its-addresses-on-1-december-2015-what-does-this-mean-for-you/ -- 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 and views
On Wed, Oct 07, 2015 at 11:35:11AM +0200, Marco Felettigh wrote:
> i have server with an old Bind (bind-9.9.4P2) and is configured
> with multiple views.
>
> ViewA that has slave zones and accept query for
> match-destinations IpA ViewB that has others slave zones and
> accept query for match-destinations IpB
>
> ViewDefault that is the a default configuration for root zones
> etc. and accept query for match-destinations IpDefault.
>
> view "ViewA" {
> match-destinations { IpA; };
"dig @IpA pippo.it." hits this view.
> transfer-source IpA;
> allow-query { any; };
> recursion no;
>
> zone pippo.it .
>
> };
>
> view "ViewB" {
> match-destinations { IpB; };
"dig @IpB pippo.it." hits this view.
> transfer-source IpB;
> allow-query { any; };
> recursion no;
> zone.
> };
>
>
> When from the server i run for example:
> dig hosta.pippo.it
>
> dig contact my resolv.conf nameserver (127.0.0.1) on port 53 but
> the Bind's resolver contact root servers and come down all the
> dns chain like Bind do not has the pippo.it zone in the ViewA.
Where is destination 127.0.0.1 matched?
> Of corse if i run
> dig hosta.pippo.it @IpA
> all is working properly.
>
> Is it possible to force the Bind's resolver
Do you mean dig, or named's internal resolver code?
> to lookup in all the views ?
Do you mean in a single query? No, only one view can be hit per
query.
The point of views is to have different answers depending on who's
asking, or in your case, where they ask. If the answers differ,
which one's the right one?
If you want to share a zone in more than one view, do as Mark
suggested: upgrade to 9.10.3 and use "in-view". You probably ought
to consider upgrading anyway, because of recent security patches.
> Important: i need the views binded to differents ips.
--
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: Caching and upper case issue with BIND 9.9.7-P3
On Wed, Sep 23, 2015 at 08:18:45AM -0700, cypher Nix wrote: > We eventually restarted BIND and the issue went away. After > restarting BIND all responses served from cache are now lower > case, as expected. Restarting is a very painful way to fix cache issues. Consider as better choices: rndc flush rndc flushtree example.com -- 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: Install BIND 9.9.7-P2 to fix vulnerability CVE-2015-5477
On Mon, Sep 07, 2015 at 12:24:36PM +0300, stavrostseriotis wrote: > I have a RedHat 5.11 machine and currently I am facing the issue > with BIND vulnerability CVE-2015-5477. I cannot update my BIND > using yum because I didn't install BIND from RedHat at the first > place so I need to do it manually. Did you keep notes on what you did originally? This would be an excellent time to refer to those notes. > I downloaded the package of version 9.9.7-P2 from isc website but > since it is not an rpm file I have to build it myself. Before you go any further you might as well grab the P3 version. CVEs-2015-5722 & -5986 are fixed therein. Granted those are not as serious as CVE-2015-5477 (which has a trivial exploit published), but it cannot hurt to have the later fixes. I concur with the other posters; rpmbuild is the best way to deviate from Red Hat's own packages. You will see that a contributor to this list maintains SRPMs for the latest BIND 9 releases. With the SRPM and rpmbuild it's not much more effort to stay current than it is to "yum upgrade bind9" from Red Hat's repo of long-past-EOL software. There's nothing wrong with such deviation; in fact it's extremely important to do so for your mission critical software. But it requires a better understanding of the OS than you seem to have. > I am wondering if you can give me a little guideline on how to > build and install the new version. I would suggest that you invest some time in learning Red Hat basic administration skills, and with it some shell basics, and you will become able to diagnose and fix these problems on your own. Good luck. -- 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: Installing bind is not very clear for me
On Thu, Sep 03, 2015 at 11:02:23PM +0200, Reindl Harald wrote: > Am 03.09.2015 um 22:59 schrieb Robert Moskowitz: > >On 09/03/2015 04:35 PM, Leandro wrote: > >>Ok ... > >>I got BIND 9.10.2-P3 working. > >>I compiled with > >> > >>./configure --with-openssl --enable-threads --with-libxml2 > >>--with-libjson > >>make > >>make install > >> > >>Json statistics channel is working and chroot is not longer > >>mandatory. > > > >But do make sure you have selinux enforced. Or run behind > >multiple firewalls... > > behind *multiple firewalls* - ?!?! - oh come on and get serious > instead promote snakeoil - I quite agree here. Firewalls that attempt to filter DNS have terrible reputations for *breaking* DNS. A single firewall is bad enough; multiple firewalls sounds like a disaster. > typically BIND is *not* running as root and hence does not need > any special handling compared to any other network service I don't know if we can say what is "typical". We can say, for running on Linux at least, that running as root is safe. A compromised named would get root after having dropped superuser privileges, so it wouldn't be able to do much. Regardless, again I quite agree that special handling is not necessary. Look at the various BIND9 security announcements over the years. When have you seen one which involved a compromise of any kind? I cannot say with authority that BIND9 has never had a compromise, but I am confident in saying I have never seen one. https://www.isc.org/blogs/summer_security_vulnerabilities/ is a recent blog posting which discusses this in detail. > get rid of the horror stories from the 1990's.. -- 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: Installing bind is not very clear for me
On Fri, Sep 04, 2015 at 05:27:18PM +, Mike Hoskins (michoski) wrote: > On 9/4/15, 1:12 PM, "bind-users-boun...@lists.isc.org on behalf > of /dev/rob0" <bind-users-boun...@lists.isc.org on behalf of > r...@gmx.co.uk> wrote: > > >On Thu, Sep 03, 2015 at 11:02:23PM +0200, Reindl Harald wrote: > >> Am 03.09.2015 um 22:59 schrieb Robert Moskowitz: > >> >But do make sure you have selinux enforced. Or run behind > >> >multiple firewalls... > >> > >> behind *multiple firewalls* - ?!?! - oh come on and get > >> serious instead promote snakeoil - > > > >I quite agree here. Firewalls that attempt to filter DNS have > >terrible reputations for *breaking* DNS. A single firewall is > >bad enough; multiple firewalls sounds like a disaster. > > True, have fixed many of those over the years, though in > fairness this is often a matter of expecting to run a > firewall (or anything) "out of box" without understanding > the config. If that's the stance of the admin, you likely > have a lot more to worry about security-wise than named > chroot. :-) In most cases of "understanding firewall config" the best answer is to TURN OFF such misfeatures as DNS filtering. It's shameful that such horrible misfeatures are marketed toward people who don't know better. Sorry, not wishing to put you on the spot as a Cisco person (I really do appreciate your contributions here, BTW), but some of the Cisco "fixup" features are really bad. "SMTP Fixup" has a long history of being pilloried on the Postfix list. > >> typically BIND is *not* running as root and hence does not need > >> any special handling compared to any other network service > > > >I don't know if we can say what is "typical". We can say, for > >running on Linux at least, that running as root is safe. A > >compromised named would get root after having dropped superuser > >privileges, so it wouldn't be able to do much. > > I probably misunderstand your response or am reading too much > into the wording. Named doesn't run as root due to -u giving up > permissions. A point I tried to make there is that while many distributors by default use "named -u " in their packages, it's not all of them, and many of us (for many reasons) stick with source straight from ISC. I still have a server which is not using named -u, but I am not losing any sleep over that. And I don't use chroot at all. > That combined with the fact chroot itself has known shortcomings > is why it's fallen out of BCP amongst name server operators. It's > not that anyone suggests the alternative to chroot is to just run > as root. You are still running as a non-privileged user > post-startup, and permissioning things appropriately to minimize > damage in the event of a compromise. I am not advocating running as root as a best practice; I agree, you're better off with "-u user". But for small-time players and beginners, it's not that big a deal. They should focus on bigger problems. > >Regardless, again I quite agree that special handling is not > >necessary. Look at the various BIND9 security announcements over > >the years. When have you seen one which involved a compromise of > >any kind? > > > >I cannot say with authority that BIND9 has never had a compromise, > >but I am confident in saying I have never seen one. > > I appreciate the viewpoint, and I can even agree with it, but the > past is not necessarily a key to the future. The reality is none > of the nastiest 0-days were ever expected. As a security > professional you try to insulate against potential risks, not just > things you have already observed. It's up to each operator to > determine appropriate cost/benefit, and this is not an argument for > chroot, but I do caution against an "I've never seen it before so > wouldn't worry about it" stance on security. Okay, conceded. You definitely win on that one. :) However, from what I understand, we're unlikely to see compromises in named, because it will ASSERT and crash before that point. Offer void where taxed or prohibited, or where attackers have outsmarted and acted before the BIND9 developers. :) -- 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: More On Split Horizon Slaves
On Sat, Aug 22, 2015 at 09:53:31AM -0500, Tim Daneliuk wrote: [ Two views, one zone name, different zone contents, same master slave: how to populate both views on the slave? ] My sense is that I need to split the internal and external host assignments on the master differently, so that the slave knows which view is which, but I am not clear on how to do this when both views are in the same namespace. https://kb.isc.org/article/AA-00296/0 https://kb.isc.org/article/AA-00851/0 -- 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: DNSSEC secondary (free)
On Thu, Aug 20, 2015 at 06:29:57PM +, Mathew Ian Eis wrote: I believe Hurricane Electric’s free DNS https://dns.he.net/ supports DNSSEC if you do zone transfers to them. (No personal Their web site does not say so: * DNSSEC - We are exploring this now It has said this for about 3.1 forevers. Does anyone know if exploration was successful? experience, but we’ve been considering using them for the same purpose, and they seem to have a good community reputation). -- 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: Can I run two name servers on one host with two IP addresses?
On Thu, Aug 20, 2015 at 02:07:57PM +0200, Robert Senger wrote: There are a number of providers out there offering secondary dns services for free or for a few bucks/month. Even DNSSEC is possible for free. This is good news! I knew there were several good choices for free DNS hosting, but this is the first I heard of them supporting signed zones. https://acc.rollernet.us/help/dns/secondary.php Are there others? I saw another one amongst your NS hosts, but that seems to be your own domain. (If you're offering secondary NS for free, please do mention your service here.) -- 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
correction
On Tue, Aug 04, 2015 at 07:14:38AM -0500, /dev/rob0 wrote: It would require some reworking of things, but you might be interested in the new BIND 9.10 feature of in-view zone option. This lets you literally include a zone from another view. See BIND 9 ARM chapter 6, zone Statement Definition and Usage, for details. I meant to specify to look in a BIND 9.10 version of the ARM for this. You won't find it in 9.9 and earlier. An online version of the ARM for 9.10 can be found here: http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.html -- 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: ERROR : - writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 - loading configuration: failure
On Mon, Aug 03, 2015 at 10:36:25PM -0500, Lawrence K. Chen, P.Eng. wrote: This unfortunately looks like the thread for me to jump on to I missed installing the last two 9.9...-p# patches, first time I built everything and was pretty much ready to do it, and then forgot all about it due to health issues. More recent one...I had I hope you're well now. got it built for Solaris x64 and was about to work on building it for Solaris SPARC when the most recent one appeared. This one carried a much strong get things patched (to me at first, then higher ups started jumping around...) It's good that you have deployed the fix for CVE-2015-5477. Those who are ignorant or foolish would say this shows the problems with free software. But that's opposed to the truth: these security reports are the strength of free software. Anyone can hack at it looking for bugs. And then those bugs get fixed. Who knows what bugs lurk inside black-box proprietary solutions? Worse, who knows if they'd be fixed? Security is in openness, standing up to the light of scrutiny. But, it turned out to be a huge mess to upgrade. The first time I ran into this error, were some really old mistakes where the admin had copy and pasted a bunch of similar zones...and missed adjusting some of the files. Since on the master side they all come from the same fileit probably didn't cause any noticeable problems for the slaves or clients. However, install upgrade on our master server...knocked it out, so I'm here looking to see what the proper fix for my situation is. This seems to be a bug fix (not allowing named to share writeable files) which has brought a lot of broken configurations out. Oops. Basically, no two slave zones (even nominally the same zone, in a different view) should EVER share the same file. Master zones can get away with file sharing, but ONLY if named does not write to the file (no allow-update, update-policy, nor auto-dnssec.) Looking for a valid easy fix here ;) Partly because coming soon they're going to demolish the DNS infrastructure that I got saddled with and feel like I done a pretty good job at re-engineering it to meet all the demands of it. But, I'm the last legacy unix systems administrator here Sad. There's nothing legacy about Unix, though. Sounds like the salesmen are winning out over the technicians, in terms of getting management to set policy. Anyways...the problem is because we had turned out existing master server into doing split/stealth (started out stealth...) DNS, while having it continue to serve as slave to delegated subdomains. So that those subdomains are propagated to our external facing slave servers. So that's where the problem comes inthe internal authoritative+ nameservers having the master collect secondary zone data from them...on the Internal view. But, then having to send that information to nameservers that hit the external view of the master. The way to select a different view on the master is to use TSIG keys. https://kb.isc.org/article/AA-00295/ So, until a few hours agoit was include a file containing all the delegated (sub)domains into both viewscausing both sides to be working off of the same file. It would require some reworking of things, but you might be interested in the new BIND 9.10 feature of in-view zone option. This lets you literally include a zone from another view. See BIND 9 ARM chapter 6, zone Statement Definition and Usage, for details. WHich seemed to work fine. As only one side is getting updates, the other side is just to feed our outside facing slaves. Well, this update wouldn't go for that. So, cloning the file and doing a global search and destroythe external view is looking zone files in a directory that is emtpy, while the internal side continus as is. To have something for the external nameservers to transfer (hopefully), I'm doing a regular sync of the file 'sec' to 'ext'. Not totally sure that's workingbut nothing filing up logs about it. So, is what I did something that'll hold...or is there an easy proper solution to this? Slave zones should be transferred using DNS. In a stealth master case, you need to populate also-notify lists, but perhaps in your case you can share some of that configuration with global or view level settings. (Better than having to set everything per zone.) To hold us/me over until they decide if its going to be BlueCat or Infoblox that replaces everything. IIUC both of those are BIND under the hood. :) Sadly, I missed both presentations due to other issuesmore sad because I found my named.iner shirt, which I was going to wear to the second presentation ;) Haha, I have one of those also. Really cool. :) -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please
Re: bind 9.8 named_stats parser
On Tue, Aug 04, 2015 at 04:01:56PM -0300, Leandro wrote: Hello , guys , im thinking about getting my bind statistics on cacti. Im looking for some parser script but so far I can not get anyone for my version, witch is 9.8. I guess by named_stats, you mean the file which is written for rndc stats. (By default that's called named.stats and found inside the directory specified in your named.conf(5) options.) I'd recommend against that. It's a relic of the past. Consider instead the statistics-channels statement: http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#statschannels Consider also moving to a supported BIND version. In particular, BIND 9.10 might be of interest, with upgraded statistics-channels functionality: https://kb.isc.org/article/AA-01123/ Is something around there ? If not I will need to deploy by my self ... then of course will share it. There too, if you're doing things the old way on abandoned old software versions, I wouldn't expect to find much interest. -- 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: About CVE-2015-5477 (An error in handling TKEY queries can cause named to exit with a REQUIRE assertion failure)
On Tue, Jul 28, 2015 at 07:06:16PM -0400, Ben Croswell wrote: Is it safe to say the only vulnerable hosts would be those accepting queries from the outside world, or would this also pertain servers getting responses from the outside world with no inbound queries? I would ask where does the outside world begin? Many sites serve users with vulnerabilities. Have you ever had botnet traffic originating from your network? (I have, not fun.) Otherwise your premise is valid; the malicious query comes to your named via port 53 UDP or TCP, not as a reply from another server. But if you're thinking it's okay because you're going to deny the query, no! This happens before named gets to that point. Your nameserver must be closed to ALL potentially hostile queries. -- 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: dynamic zone file style
On Wed, Jul 08, 2015 at 05:38:59PM +0200, stefan.las...@t-systems.com wrote: Mark Andrews: By default, the bind daemon uses the relative style (or something similar) when writing dynamic zone files to disk. Guess what... all those $ORIGIN lines make it more difficult to parse the f ile by a separate script... ;) Truly, you don't wan't to be reading master files. If you need the content of the zone transfer it from the server. Doing that you will always get the latest content and don't have to worry about merging the journal etc. I understand your point. But for the script, I'll need the content of all my zones in all views. Zone transfers won't be very efficient for that. I am not sure how you figure this. I think a $ dig @127.0.0.1 example.com axfr will be far MORE efficient than a $ cat /path/to/zonefile/for/example.com In the former you are writing/reading an UDP socket on localhost, receiving data which is in named's memory. In the latter you are opening and reading from a file on disk, which, as noted by Mark, might not contain all the data you need. Until now I have experimented with the -j option from named-compilezone to take care of the journals. Though, I'm not sure this is much more efficient. Another option I evaluated was rndc sync, but it isn't available on bind 9.8 I suppose you know this already, but 9.8 is in EOL status. But your reply made me think of yet another solution. rndc dumpdb -zones gives me the latest content of all zones of all views in a single file. And, luckily, it uses the full style :) So this should be fine for me. But before I try to re-invent the wheel: Does anyone know if there is already a parser for multiple zone_files/zone_dumps/zone_transfers? I'm trying to filter all DNS records that are related to a given host/ip? -- 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: file descriptor exceeds limit
On Fri, Jun 19, 2015 at 02:55:23PM -0500, I wrote: On Thu, Jun 18, 2015 at 11:11:16PM +, Mike Hoskins (michoski) wrote: snip Note that connection tracking can be a problem upstream as well, for the same reasons as described in the article. I would still turn off conntrack for UDP DNS upstream, unless you're using DNAT (yuck.) Oh ... hahaha ... I missed the @cisco.com, so I don't suppose you're using Linux on your upstream routers. :) The same idea applies regardless of implementation, of course. -- 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: file descriptor exceeds limit
On Thu, Jun 18, 2015 at 11:11:16PM +, Mike Hoskins (michoski) wrote: On 6/18/15, 7:09 PM, Stuart Browne stuart.bro...@bomboratech.com.au wrote: Just wondering. You mention you're using RHEL6; are you also getting messages in 'dmesg' about connection tracking tables being full? You may need some 'NOTRACK' rules in your iptables. Just following along, for the record... On our side, iptables is completely disabled. We do that sort of thing upstream on dedicated firewalls. There is a Knowledge Base article about this: https://kb.isc.org/article/AA-01183/ Note that connection tracking can be a problem upstream as well, for the same reasons as described in the article. I would still turn off conntrack for UDP DNS upstream, unless you're using DNAT (yuck.) Just now getting time to reply to Cathy...more detail on that there. -- 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-users] Re: BIND9-ARM (HTML) feature request: better hyperlinking in/of chapter 6
On Sun, May 10, 2015 at 02:39:04AM +, Evan Hunt wrote: On Sat, May 09, 2015 at 04:56:08PM -0500, Jerry K wrote: Was going thru some old messages, and came across this one about generating the ARM doc as HTML. Just wondering if anything ever became of it? The ARM is generated as HTML now, but the request in that thread was to add better anchor tags for each option, so you could look up Bv9ARM.ch06.html#response-policy or whatever, and be taken to the corresponding section of the ARM. Good idea, nobody's done it yet. Oops, sorry. When I suggested it I was unemployed, and now [thankfully] am not. $Dayjob keeps me busy, but now I have more clue about the docbook, so I'll try to do what I can. -- 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: Getting an error on a very simple DNS configuration
On Wed, Apr 08, 2015 at 11:01:30PM +0100, Steven Carr wrote: You're missing a whole swaythe of required declarations for BIND to be able to handle recursion. Not so. In fact named with an empty named.conf has built-in hints, plus default settings, which makes it work fine. The allow-recursion default is localhost; localnets; so it should answer queries from the same host and from any locally-connected networks. There are numerous examples via google, first one that is returned There's also the ISC KB, https://kb.isc.org/ and even an article which covers compiling from source and running a simple named for recursion: https://kb.isc.org/article/AA-00768/ -- 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: com.google how did they do that
On Wed, Apr 01, 2015 at 02:42:04PM -0400, Thomas Schulz wrote: As of the time I am sending this, you can point your browser to http://com.google and get a web page. How did they get com.google to resolve? I'm sure it was not cheap. Brace yourself! There are many here now, and more coming. -- 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
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: 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
Re: Single slave zone definition for two view (cache file name problem)
On Wed, Mar 18, 2015 at 11:48:40AM +0300, Constantin Stefanov wrote:
I see why it may lead to problems.
But in fact the configuration with only one writable file
referenced several times is suported now. If I write:
view view1 {
zone aaa.exampe.org {
masters {IP;};
file slave/aaa.exmaple.org;
};
};
view view2 {
zone aaa.exampe.org {
in-view view1;
};
};
then both views will refernce ther same writable file, won't they?
No.
Or am I missing something about in-view directive?
Perhaps. The view2 reads zone data from view1, which in turn reads
data from the file (and its journal.) Notifies from the master are
directed to view1, which does the IXFR or AXFR and writes the
journal. There is no shared access to a journal.
And if I'm right, the only question is how to simplify the
configuration so not to have two definitions in two files for
every slave zone which is shared between views.
I can think of two possible ways to do what you want, each using
multiple, separate files for each zone (one file/journal per view.)
I don't believe either way exists right now, but perhaps one of these
ideas would make a reasonable feature request.
The first way would be if a view could have its own directory
option set. Then the relative paths in your example above would
point to different directories. The ARM is not explicit as to
whether or not this is possible, but some simple experimentation
would quickly determine the answer.
The second way definitely does NOT exist, and that would be to have
some kind of variable in the named.conf syntax to refer to the name
of the current view.
--
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: Single slave zone definition for two view (cache file name problem)
On Tue, Mar 17, 2015 at 05:36:57PM +0300, Constantin Stefanov wrote:
After upgrading from BIND 4.6 to 4.10.2, named requires that
different slave zone have separate file for cache.
Surely you mean s/4/9/g, and yes, this is true.
With 4.6 I had the following config:
named.conf:
view internal {
match /* match condition */;
include common.zones;
};
view external {
match /* match condition */;
include common.zones;
};
common.zones:
zone aaa.example.org {
type slave;
file slave/aaa.example.org;
masters {MASTERIP;};
};
It worked fine with 4.6 (although it was considered incorrect).
After upgrade to 4.10 named started complaining:
common.zones:3: writeable file 'slave/aaa.example.org': already in
use: common.zones:3
As I understand, now I need to have separate files for different
views.
But is there a way to have them automatically assigned and to write
something like:
file slave/aaa.example.org.${view_name}
or any other way to have only one defininition for common zones?
Here is an easy suggestion:
view common {
match-clients { none; };
zone example.com {
type slave;
file common/example.com;
masters { example.com-masters; };
};
// repeat for other common zones
};
And then your other views can be defined and use the include file as
before, with each zone being:
in-view common;
I found 'in-view' option, but again it requires two definitions for
every zone: one with file and masters directives, and another
with in-view option. Moreover, these two definitions must be in
different files, as I have to include one in first view, and
another (with 'in-view') in all other views, so I have to keep two
separate files synced with one another.
So is it possible to have only one definition for slave zones that
are shared between different views?
Hmmm. I am not sure if there is a good workaround for that. But
there are tools like make(1) which can do this for you? I would
suggest a script to generate the common.zones file from whatever
you're using for the common view.
Maybe someone else will have a better suggestion?
--
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: forwarder and cache
On Mon, Mar 16, 2015 at 10:36:40AM -0700, Dana Huggard wrote: I have a problem with a host lookup failing, but then succeeds after I restart bind9. The reverse look succeeds before the restart. There are two bind servers. A and B. Server A is master for A.domain and B is master for B.domain. Server A has a ZONE B configuration entry declaring B as the forwarder. It's usually better to use regular DNS delegation to make this work properly. Server B also runs dhcpd with ddns. A new computer comes up via dhcp on the B domain and network. If I query the hostname using B as my resolver I get and answer, If I query the hostname using A as my resolver I get NXDOMAIN. If I then restart bind on A, and re-run the same query that failed before, it now succeeds. Restarting is overkill. Try rndc flush. I don't understand why this is behaving this way. Any ideas? My best guess here is negative caching? If you (or any user of resolver A) had queried that name in zone B during the period defined in zone B's SOA minimum field (the last numeric field in the SOA), the NXDOMAIN result is cached. For more help show your actual dig commands and results. -- 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: unable-resolving
On Mon, Mar 09, 2015 at 10:07:55AM +0300, Mohammed Ejaz wrote: This lately we have been receiving complain from our customer that they are unable to open the websites when they use our DNS server (ns1.cyberia.net.sa) , one of the Eg. Is www.twitter.com, it works only If I removed my internal cache it works for some time. And after some time it won't. Our DNS sometimes resolves the domain and sometimes are not This is not enough information to be able to diagnose the problem. Other posters have already guessed that you might not have had recursion enabled for your clients, but that's not consistent with the SERVFAIL result you showed below. Default Server: ns1.cyberia.net.sa Address: 212.119.64.2 www.twitter.com Server: ns1.cyberia.net.sa Address: 212.119.64.2 *** ns1.cyberia.net.sa can't find www.twitter.com: Server failed Two suggestions: first, get rid of nslookup. Use dig and share the dig query and result with the list. Second, check your logs for the exact time of these SERVFAIL responses you're seeing. Sometimes these will be logged. -- 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: Too many connections on the same IP
On Wed, Mar 04, 2015 at 09:47:59AM +0100, stefan.las...@t-systems.com wrote: Are you using iptables Firewall? Does the problem only occur on UDP connections to the problematic IP? Or also on TCP connections to the same IP? I had similar problems (not with bind) when the connection table of iptables state module were too small. Iptables started dropping packets, because it couldn't keep track of new connections. The ISC Knowledge Base has an article about this: https://kb.isc.org/article/AA-01183 Since UDP is by definition stateless, the state module tries to invent some sort of connection status, based on source- and destination ports. Linux connection tracking is protocol-agnostic, but yes, aspects of the protocol (such as source and destination ports if applicable) are considered in defining a what is considered a connection. This sometimes makes trouble. Especially when there are lots of concurrent connections and the same UDP-ports show up over and over again (e.g. when DNS-Clients do not use Source Port Randomization). The trouble comes if/when the table is too small to account for many random ports. Each connection is only two packets: a query coming in, and a reply going out. You could try to remove the state module (-m state --state NEW) from your UDP firewall rule for BIND and see if that helps. It probably would not, because each query/reply is still seen as a connection to the kernel. A more sophisticated and effective approach is as described in the article above, using the raw table and -j CT --notrack. I believe there are separate state tables for each network interface. This could explain, why your second IP is still responding. There is a single conntrack table for the system, and all entries therein are based on packet header information: source and destination IP address (and ports if applicable.) We really don't have enough information in this thread to be able to answer the OP's questions. -- 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: dynamic update of split view acl
On Sat, Feb 28, 2015 at 04:27:36AM -0800, Matt Calder wrote:
I'm running BIND 9.9.5-3 on Ubuntu 14.04.1.
I'm trying to figure out how to change the match-clients prefixes
in a view without having to restart BIND or do full config reload.
My actual BIND config has many views and restarts can take several
minutes.
Did you try rndc reconfig? That might be a bit faster because it
doesn't reload zones.
Here is my simple test set up.
Unfortunately HTMLified by your MUA.
*view view1 {match-clients { 204.57.0.0/24
http://204.57.0.0/24; 204.57.5.0/24 http://204.57.5.0/24; };zone
domaintest.com http://domaintest.com/ in {type master;
file /etc/bind/view1.zone;};};view view2 {match-clients
{ 216.55.18.0/24 http://216.55.18.0/24; };zone domaintest.com
http://domaintest.com/ in {type master;file
/etc/bind/view2.zone;};};*
I'd recommend using acl statements:
#v+
# here I am naming each component network
# (use names that make sense to you)
acl net-57-0 { 204.57.0.0/24; };
acl net-57-5 { 204.57.5.0/24; };
acl net-216-55-18 { 216.55.18.0/24; };
# and then I build the composite networks per view
acl view1 { net-57-0; net-57-5; };
acl view2 { net-216-55-18; };
# That done, use the composites as match-clients:
view view1 {
match-clients { view1; };
... (other view stuff) ...
};
view view2 {
match-clients { view2; };
... (other view stuff) ...
};
#v-
Say I move 204.57.0.0/24 from view1 to view2, my hope was that I
could simply do
*$ rndc reload domaintest.com http://domaintest.com/ in view1
$ rndc reload domaintest.com http://domaintest.com/ in view2*
and match-clients would also be updated but this doesn’t work.
I increment the serial of view1.zone and view2.zone, but
204.57.0.0/24 is still matched by view1. Is there any way to
accomplish this?
Right. So you redo your acl statements and do rndc reconfig.
The acls are simply there to make it easier to manage. The real
answer is reconfig. That will work even without acls.
--
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: Share RPZ Zones between views
On Fri, Feb 20, 2015 at 02:58:00PM +, Howard, Christopher wrote: I do not believe it is possible to have the other views reference records that are only loaded in another view. BIND 9.10 has this feature, the in-view zone option. -- 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: Setup our OWN DNS Server
On Fri, Jan 30, 2015 at 03:35:10PM +0800, Chandran Manikandan wrote: I have email,web and FTP server hosting on our in house with public ip on Centos 6 on our own server. But email,web,ftp dns hosting with other third party service provider. I have enough public ip to host dns server for our own. So what are the requirements to host dns server and how to setup. Could anyone guide me. There are good things to be said about staying with third-party DNS hosting: they have capacity, redundancy, experience (one would hope anyway. :) ) Furthermore reasonably good DNS hosting can be had for free (or very close to it.) This is not to discourage you nor anyone else from learning DNS; but when doing so you might consider keeping the main zone hosted with professional DNS providers while delegating a play zone to your servers. Those who do wish to become DNS professionals might consider taking the training offered by ISC. My class was with Alan, and while I went into it with more experience than some class members had, it was an excellent exercise with lots of hands-on work. I think new DNS administrators come out of it with a lot more confidence. Some people like the dead-tree stuff, and while most of that's still relevant, it is impossible for printed media to keep up with the technology. The BIND 9 ARM is the source of documentation for BIND, and also helps new users get up to speed on basic DNS concepts. Highly recommended and readily available; you should have HTML and PDF copies of the ARM with your copy of BIND (check with your distributor to see if documentation is in a separate package.) Here's the link if you can't find your copy: https://kb.isc.org/article/AA-01031 Finally, of course, this mailing list has a lot of experienced people, willing to help you out if you get stuck. Good luck! -- 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 in FreeBSD 10
On Thu, Jan 22, 2015 at 07:17:44PM -0700, LuKreme wrote: I know FreeBSD requires you to install bind if you need it as of version 10, but what i can’t find is if the packages bind910 and bind-tools overlap completely or not. That is, do I install bind-tools if bind is installed? That question is better suited for a FreeBSD support list. Also, just quickly, is there a consensus on running 9.10 over 9.9? That's tough to say. Depends on your needs. Look at the 9.10 new features. If you need those, you probably do want 9.10. A couple of nice ones off the top of my head: the new in-view zone option for sharing zones among views (useful in multiple-view authoritative nameservers); and the prefetch feature for recursive resolvers. And of course on the tools side, 9.10 boasts the new delv(1) tool. 9.9 is the current Extended Support Version (ESV), so it's likely to outlive 9.10. If you're after long-term stability, ESV might be important to you. -- 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: Disable DNSSEC Validation for selected Domains
-Ursprüngliche Nachricht- Von: Evan Hunt [mailto:e...@isc.org] On Jan 13, 2015, at 2:35 AM, stefan.las...@t-systems.com wrote: I'm just wondering, is an option like unbound's domain-insecure intentionally not implemented in in BIND? Or did just nobody care enough to implement it yet? I have resisted implementing it because it's too easy for an operator to forget they knocked a hole in their DNSSEC protections, and leave the hole in place long after it stopped being useful. The negative trust anchor implementation that will be released in 9.11 corrects for this with built-in term limits. NTAs are added via rndc, and they expire and are removed after a relatively short lifespan, not exceeding a week. On Wed, Jan 14, 2015 at 10:34:35AM +0100, stefan.las...@t-systems.com wrote: Hm... In our case a short lifespan won't be enough. I hate to point this out, but a simple workaround to make NTAs permanent is to have a cron job which runs your rndc nta command as often as needed. May Evan and the gods of DNSSEC have mercy on my soul! :( Our customer uses a fictional Toplevel Domain and migrating the whole Infrastructure to a new, proper Domain will take him months if not years. They'll have to adjust every DNS Config of every Server, every Webservice they have running internally, all Documentations etc... I wouldn't be surprised if they are not even aware of the problem, yet. -- 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: DNSSEC
On Sat, Jan 17, 2015 at 11:43:33AM -0500, John wrote: is there a separate DNSSEC mailing list? If *you* are using BIND for signing or validation, anything pertaining to DNSSEC is quite relevant here. Google for dnssec mailing list brought up a few possibilities. -- 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: slave fail to ixfr from master
On Sun, Sep 14, 2014 at 04:40:52PM +0800, Liu Mingxing wrote: Our slave can not get ixfr data from master, the soa number in the slave is smaller than one of the master and no responding lines are not found in the notity log. However, in the slave server, connections about both of them are found with tcpdump. to reboot the named can not fix the problem. Do you meet with the problem? how to fix it? Show us the things you have described; host -C example.com shows all the listed NS hosts and their SOA records. Why are notifies (apparently) not being sent? Maybe this slave is not an NS host? (That's what also-notify in the master zone definition is for.) Also check that the master lists this slave in its allow-transfer setting, either in global options or in the zone definition. Also include logs and configuration from both master and slave, if this wasn't enough to get it figured out. -- 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: Two domains reporting errors
I know you said, Never mind, but you seem to be misunderstanding something here ... On Tue, Sep 09, 2014 at 07:42:56PM -0600, LuKreme wrote: # named-checkconf -z | grep -v loaded master/bt.tld:3: ignoring out-of-zone data (bt.tld) master/bt.tld:15: ignoring out-of-zone data (webdav.bt.tld) _default/dw.tld/IN: bad zone master/bt.tld:16: ignoring out-of-zone data (www.bt.tld) zone dw.tld/IN: has 0 SOA records zone dw.tld/IN: has no NS records So, line 3 in bt.tld is the SOA line which looks as far as I can tell, basically identical to every other file: You said this several times, but at least one was significantly different. == master/covisp.net == $ORIGIN . $TTL 86400 ; 1 day covisp.net IN SOA covisp.net. root.covisp.net. ( You set $ORIGIN . so your unqualified covisp.net is in fact covisp.net. (fully qualified.) == master/bt.tld == $ORIGIN . $TTL 86400 ; 1 day bt.tldIN SOA bt.tld. root.covisp.net. ( Here also. For the second domain, I don't understand the _default/dw.tld/IN error at all, and the file starts like all the others: # head -3 master/dw.tld $ORIGIN . $TTL 86400 @IN SOA dw.tld. root.covisp.net. ( @ refers to the current $ORIGIN. When a zone file is initially loaded, $ORIGIN is implicitly set to the name of the zone. But you changed that, it's now the root! So @ here means ., and no, a zone file with @ is not the same as a zone file with an explicit owner name for the SOA. My style recommendation: do not use $ORIGIN lines in zone files. Whilst named does it, you do not have to copy named. Leave out $ORIGIN, use @ to refer to the name of the zone, and unqualified owner names beneath @. $TTL 1d @ IN SOA ns hostmaster ( ... @ IN NS ns @ IN NS ns1 @ IN NS ns2 @ IN MX 0 mail mailIN A 192.0.2.25 ns IN A 192.0.2.53 ns1 IN A 192.0.2.35 ns2 IN A 192.0.2.36 Note that there are only relative names in my example. This could load as any zone name. You might want to use some fully-qualified names on the RHS, such as root.covisp.net. as the SOA RNAME. -- 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: A record of domain name must be name server ?
On Mon, Sep 08, 2014 at 03:43:22PM +0800, Pete Fong wrote: The below item is our DNS (BIND) server configuration. our Domain* xxx.com I think that is a porn site. If you mean to use that name as an example, please use example.com instead. Putting HTTP links to pornography in your emails is a sure way to fall afoul of various content filtering solutions which are in common use. See RFC 2606 regarding reserved domain names like example.com. http://xxx.com *is assigned IP address 192.168.1.100 which is our one of DNS server. Can we change it to our web server IP address ? Because we want anybody access our domain *xxx.com http://xxx.com* with internet browser then it will go to our webpage. Am I correct ? I really appreciate anybody help. It's not unusual to point an A record for @ at a HTTP server. Whatever you are not understanding here, I can't tell. @ IN SOA ns1.xxx.com. root.ns1.xxx.com ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1.xxx.com. IN A 192.168.1.100 This zone file would fail named-checkzone(8) testing if loaded as xxx.com, because there is no A record for the NS name, ns1.xxx.com. This zone would fail to load. If any of your NS names are inside the zone, you must have either or both A and records for those NS names. Here is the same zone without the XXX and with all relative names: @ IN SOA ns1 root.ns1 ( 2014090801 ; serial 2h ; refresh 10m; retry 1w ; expiry 1h ) IN NS ns1 IN A 192.168.1.100 ns1 IN A 192.168.1.100 -- 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: DNS reverse sub delegation NXDOMAIN problem, Class C
Sorry, this is going to be a pedantic post, so I might as well start here: Subject: Re: DNS reverse sub delegation NXDOMAIN problem, Class C No, there's no such thing as Class C, so please forget that. It's a /24 network. CIDR is in; class is dismissed. On Tue, Aug 19, 2014 at 07:03:20PM +0200, Matus UHLAR - fantomas wrote: On 19.08.14 11:54, Bazy V wrote: One post said 220/24 is not the correct format, Another post said that is the format. no post said this. Right. I wonder where the OP got that idea? Not sure which one is correct. 220.20.172.IN-ADDR.ARPA is the correct zone into which to put PTR records. Setting 220NSns2.sub.test.com. Test.com is a real Internet domain. Please don't use that if you aren't the actual owner. this belongs to the 20.172.IN-ADDR.ARPA domain Yes, to repeat, and enhanced for RFC 2606 compliance: 220 NS ns2.sub.example.com. on your recursive nameserver - the one your resolv.conf points to. Well no, not necessarily. This is authoritative service we are discussing here. That said, sure, typically you're going to host such internal-only zones on a server that also does recursion. That's not required, however. The recursive server could have stub or static-stub zones, or even an alternate root zone, which points to the authoritative server. Pedantry complete. -- 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: Root servers
On Fri, Aug 15, 2014 at 10:14:09AM -0400, Thomas Schulz wrote: I wrote: On Thu, Aug 14, 2014 at 02:26:54PM -0500, Bill Christensen wrote: It looks like my root pointers are horribly out of date. Seems to me this is something which should automatically update... Not much, and yes. ; This file is made available by InterNIC ; under anonymous FTP as ; file/domain/named.root ; on server FTP.INTERNIC.NET ; -OR-RS.INTERNIC.NET ; ; last update:Feb 04, 2008 ; related version of root zone: 2008020400 That's old, but not so old as to prevent you from reaching an actual root server. Of course it was 2 years before the root was signed. I will add my $0.02. The named executable has the root information built in so that it can start up if there is no named.root file available. So, if you had no named.root file but did have the latest release of Bind then you would have the current data. If you do not update Bind the moment that a new version is released then you need a current named.root file. Not really. There are enough valid servers from 2008020400 to be able to resolve ./IN/NS now. In fact I bet you could turn on an ancient BIND 4 today and still be able to resolve the root. Just go get a new one from the server listed at the top of the old file. Sure, that's good advice, which is why I left it in the posted message. But probably better advice is to upgrade to a supported BIND version. If the OS is so old to be have a 2008020400 hint file, it probably means no updates have been done along the way. -- 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: Root servers
On Thu, Aug 14, 2014 at 02:26:54PM -0500, Bill Christensen wrote: I'm seeing some root server errors on startup: 14-Aug-2014 13:14:08.142 info: host unreachable resolving 'd.gtld-servers.net//IN': 2001:503:ba3e::2:30#53 14-Aug-2014 13:14:08.215 info: host unreachable resolving 'b.gtld-servers.net/A/IN': 2001:503:231d::2:30#53 14-Aug-2014 13:14:08.220 info: host unreachable resolving 'c.gtld-servers.net/A/IN': 2001:503:231d::2:30#53 14-Aug-2014 13:14:08.522 info: host unreachable resolving 'd.gtld-servers.net//IN': 2001:503:83eb::2:31#53 14-Aug-2014 13:14:08.595 info: host unreachable resolving 'c.gtld-servers.net/A/IN': 2001:503:a83e::2:31#53 14-Aug-2014 13:14:08.793 info: host unreachable resolving 'b.gtld-servers.net//IN': 2001:503:c27::2:30#53 14-Aug-2014 13:14:08.794 info: host unreachable resolving 'b.gtld-servers.net//IN': 2001:dc3::35#53 14-Aug-2014 13:14:08.795 info: host unreachable resolving 'c.gtld-servers.net//IN': 2001:503:c27::2:30#53 14-Aug-2014 13:14:08.796 info: host unreachable resolving 'c.gtld-servers.net//IN': 2001:dc3::35#53 How do I correct that? It looks like your system thinks it has IPv6 connectivity, but it doesn't really have it. You can disable IPv6 at the OS level or: named -4. It looks like my root pointers are horribly out of date. Seems to me this is something which should automatically update... Not much, and yes. ; This file is made available by InterNIC ; under anonymous FTP as ; file/domain/named.root ; on server FTP.INTERNIC.NET ; -OR-RS.INTERNIC.NET ; ; last update:Feb 04, 2008 ; related version of root zone: 2008020400 That's old, but not so old as to prevent you from reaching an actual root server. Of course it was 2 years before the root was signed. -- 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: Metazones or Something Else?
On Tue, Aug 05, 2014 at 09:31:31AM -0400, Brian Cuttler wrote: On Tue, Aug 05, 2014 at 09:21:07AM -0400, Brian Cuttler wrote: rndc addzone sounds like a very interesting tool, but if you want an automated sync, will require something to read the source config of the master and then write the requisit slave zone information for the dns slave server(s). Offsite slave servers will require a lot of trust. - I guess not just trust, but some form of ACL so that remote managers can add/remove/edit only certain zones. This may be even a larger security issue than a technical issue. The slave trusts the master. The master would have to control the access permissions. Dual-level access control would be hard to implement, and not make much sense. rndc.conf(5) does not provide flexibility in controlling access to specific subcommands. (Evan, is that a feature you have thought about?) So you'd probably have to use something like a web form, authenticating users and keeping track of which user controls which zones. Rsync solution for onsite servers will result in duplicate copies of the master or the slave, unless you automate a wrapper for that too (and I'm inclined to think in terms of # sed, which I use in a surprising number of my scripts). named-checkconf -p, piped through sed, can easily convert master zones to slaves. But rndc addzone can be automated. Have the web form ssh to the slave[s] with the name of the new zone, there run a script to add the zone. As an alternative, you could have the controls channel accessible to the master over the network (perhaps a VPN for added security), and simply have the web form do the rndc addzone remotely. Lots of choices, not easy to say what's best. Except that addzone (and delzone also) works at runtime, not requiring a separate rndc reconfig to load (or remove) zones. -- 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
rndc (was: Re: Reload BIND ...)
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote: i am doing reloads of named with killall -HUP named just because i disabled rndc completly for security reasons and configurations are generated with own software only needs named to reload Hmm, rndc is securable. You don't have to open it to the Internet; typically you'd just bind it on 127.0.0.1. Then your rndc key will further secure it against system users. Your OS can probably give extra protective layers by firewalling it, such as this Linux example: iptables -vA OUTPUT -p tcp --dport 953 -m owner \ \! --gid-owner wheel -j REJECT (This forces root and other wheel members to chgrp wheel before they can use rndc, as an extra inconvenience.) Another option is to use a UNIX domain socket, which, of course avoids the network altogether.[1] You're losing a lot of new features without rndc. This is a throwing out the baby with the bathwater sort of solution. Sure, this is what you are familiar with and what works for you, but to disable rndc isn't good advice for readers of this list. ISC is moving on. See Bv9ARM.ch06.html#controls_statement_definition_and_usage and rndc-confgen(8). [1] Unfortunately it is not clear to me how to access the socket with rndc. The one time I tried it, I gave up and stuck with that with which I am familiar. ISC moved on, but if the documentation did, I don't see it. :) -- 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: rndc
On Thu, Jul 31, 2014 at 12:11:40PM -0400, Kevin Darcy wrote: kill -HUP is way more disruptive than necessary for a mere interface scan. It's overkill. Furthermore, on a server with lots of zones, it could cause a DoS while zones are reloading, and named is unable to answer. -- 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: rndc (and now nsupdate too)
On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote: Am 31.07.2014 um 17:41 schrieb /dev/rob0: On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote: i am doing reloads of named with killall -HUP named just because i disabled rndc completly for security reasons and configurations are generated with own software only needs named to reload Hmm, rndc is securable. You don't have to open it to the snip You're losing a lot of new features without rndc. This is a throwing out the baby with the bathwater sort of solution. Sure, this is what you are familiar with and what works for you, but to disable rndc isn't good advice for readers of this list. ISC is moving on don't get me wrong but if someone creates *any* bind configuration and zone-files with self developed software ... that someone is almost surely doing it wrong. Zone files? there are no features rndc could provide and so disable something you don't use is the way to go instead make is secure with other switches The proper tool to manage named configuration and operation, and which in the best Unix ethic is well suited for automation, is rndc(8). The proper tool to manage zone data is nsupdate(8). Likewise well suited for automation. Unfortunately, it seems that no one with an adequate understanding of BIND has written and released a good management frontend. Too many of them are still wallowing around in zone file editing rather than nsupdate and (as it seems from this thread) sending of signals rather than rndc. -- 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: Why the heck my NS are not working
On Sun, Jul 20, 2014 at 10:12:19PM +0530, Blason R wrote: Ah, so this is funny Godaddy DNS settings!!! Crap I have setup vanity nameservers but seems it is still pointing to Godaddy DNS IP Addresses. And the most funny part is no body knows at gdaddy how to delegate my DNS servers since I am using premium DNS serves. Perhaps a Godaddy-to-DNS terminology translation will help? The Godaddy word for glue is domain hosts. (Caveat: it has been in excess of a year since I have seen the Godaddy user interface. This translation offer is void where taxed or prohibited, or if they made changes in the meantime.) Make a domain host entry for each of your NS hosts for which you need glue, that is, where the NS name is within the delegated namespace. Create your zone on the to-be-delegated nameservers. Test with directed dig commands to be sure it works: dig isnlab.in. any @your.ns.ip.addr You should see an authoritative reply with the zone data you configured. And yes, you definitely DO need your own SOA with a proper mname, rname, and updated (higher) serial. Finally, point NS in the Godaddy domain panel to your new nameservers, and Bob's your uncle. I have no idea about Godaddy's premium DNS. It probably means you gave them extra money that you should not have given, if you planned to be running your own nameservers. I bet they won't refund it. On Sun, Jul 20, 2014 at 9:57 PM, Chris Thompson c...@cam.ac.uk wrote: On Jul 20 2014, Blason R wrote: The domain is isnlab.in and host i am trying to ping is lbtest.isnlab.in The glue for delegation isnlab,in is out of step with (various) in-zone contents. The in servers give a referral to snip -- 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: Slave zero-TTL on CNAMES
On Thu, Jun 05, 2014 at 05:21:47PM +0200, Reindl Harald wrote: what the hell invents $TTL 0 ; 0 seconds lines before each CNAME block while on the master there is exactly one TTL line with 86400 on top of the file? The way named writes a zone file is not the way I would do it. Records are strictly in alphabetic order, and $TTL blocks are made around all RRSETs where TTL varies. The zone FILE is not your problem. I don't know exactly what the problem might be. It seems that something is intercepting and filtering the zone transfers? You could try transfers manually from the slave: dig [key auth if required] rhsoft.net. axfr @91.118.73.16 Does that show any zero TTLs? If so I suggest you place a couple of sniffers at strategic spots, one leaving the master, another entering the slave, and force a zone transfer. -- 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: logging via named.conf
On Wed, May 28, 2014 at 09:58:39PM -0700, Jim Pazarena wrote:
Is there an easy way in the named.conf logging to
have ALL logging go to local2 ?
I've created:
logging {
channel syslog-local2 {
syslog local2;
print-category yes;
print-severity yes;
};
category default { syslog-local2; };
};
// Stop, right here! You're done.
/*
category general { syslog-local2; };
category database { syslog-local2; };
category security { syslog-local2; };
--More--(44%)
*/
/QUOTE
A lot of messages get to local2, but some things (like
general.warning) don't get to local2, but still get to
syslog messages.
Do you mean to other facilities, such as daemon, the default?
Is there an easy catch-all for ALL named logging ?
category default covers everything not specifically listed. When
other categories are listed in the logging stanza, those are removed
from category default.
--
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: bin 9.10 verbose logging
On Sun, May 04, 2014 at 01:32:18PM +1000, Noel Butler wrote:
On 04/05/2014 05:28, Jeremy C. Reed wrote:
It is at the notice severity level. The code says:
We didn't get a OPT record in response to a EDNS query. and
also says We need to drop/remove the logging here when we have
more experience.
Are you getting this debugging for EDNS-related problems for
every request? Maybe need to realize why.
Yes, at a guess I'd day every single request to the caching
server was logging, daemon log which rarely sees more than
200k a week, grew to 210mb in 24 hours :)
Maybe you can change the setting in
from ISC_LOG_NOTICE to ISC_LOG_DEBUG(10) in your
./lib/dns/resolver.c.
that didnt seem to do anything, I'm going to revert that
server back to 9.9.5 to stop this madness. I'll maybe look
for a logging option to null out, tomorrow.
This is what I use for a logging statement:
logging {
channel default_log {
file logs/named.log versions unlimited size 10485760;
severity dynamic;
print-time yes;
print-severity yes;
print-category yes;
};
channel query_log {
file logs/query.log versions 5 size 5242880;
severity dynamic;
print-time yes;
};
category default {
default_log;
};
category queries {
query_log;
};
};
The print-category and print-severity in the default_log file will
quickly show you which category + severity is causing the noise.
Then, you can define another channel to deal with those as you
consider necessary / best.
Refer to ARM chapter 6 for details:
bind-9.10.0/doc/arm/Bv9ARM.ch06.html#id2574892
--
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
