questions about rndc zonestatus
Hi! I would like to use this feature to check the status of my slave zones. # rndc zonestatus nic.at name: nic.at type: slave files: /etc/bind/zones/nic.at serial: 2017121119 nodes: 77 next refresh: Tue, 19 Dec 2017 08:34:53 GMT expires: Tue, 02 Jan 2018 07:50:08 GMT secure: yes inline signing: no key maintenance: none dynamic: no reconfigurable via modzone: no Unfortunately the slave-status is not dumped, e.g. if the zone is n sync, if SOA refresh-checks suceed, if XFRs succeed? Do I miss something? In the above example the configured masters is not available and SOA-checks and XFR failed. Nevertheless there is no information about the failing refresh checks for the zone. Further, I would like to know if there are existing tools to parse the output, or if it is possible to get the data in a more structured form. Further it would be great to get a dump of all zones (e.g. without specifying the zone), or at least to get a dump of the configured zone of Bind. thanks Klaus ___ 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 about rndc zonestatus
Klaus Darilion wrote:
>
> Unfortunately the slave-status is not dumped, e.g. if the zone is n
> sync, if SOA refresh-checks suceed, if XFRs succeed?
I agree this is could be improved.
> Further, I would like to know if there are existing tools to parse the
> output, or if it is possible to get the data in a more structured form.
Hmm, I thought that should be available via the statistics channel, but
sadly not.
> Further it would be great to get a dump of all zones (e.g. without
> specifying the zone), or at least to get a dump of the configured zone
> of Bind.
This I can help with :-) and coincidentally I was playing around with it
yesterday. Last year I wrote about getting a list of zones from BIND's
json statistics channel: https://fanf.livejournal.com/146763.html
I find jq quite handy for wrangling json, but rather brain bending as a
programming language. The script I wrote in that articles was a bit
contorted. Yesterday I worked out a better version which is much more
linear:
$ curl -Ssf http://[::1]:8053/json |
jq -S -r '.views |
to_entries |
map({ view: .key, zone: .value.zones[] }) |
.[] |
"\(.zone.name) \(.zone.class) \(.view) \(.zone.type)"'
There's also `named-checkconf -l` which lists the configured zones (and
was a feature submited by me!). It omits things like catalog zones and the
_bind view which are listed by the statistics channel, because it works on
the text of the configuration file. (I can't remember whether it includes
zones added by `rndc addzone` - I guess not.)
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Viking, North Utsire, South Utsire, Forties: Southerly or southwesterly,
veering northwesterly later, 5 or 6, decreasing 4 at times, occasionally 7
except in South Utsire. Moderate, occasionally rough in Viking and North
Utsire. Occasional rain, fog patches. Moderate or good, occasionally very
poor.
___
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-Format-Eroor
On Tue, Dec 19, 2017 at 09:28:28AM +0300, Mohammed Ejaz wrote: > > No this IP 212.76.76.18 doesn’t belongs to us and even not in a > trusted list of our DNS. After looking at my logs I noticed this IP > asked for this domain mumbai-m.site to which our name server denied > as shown in the below logs. Whereas our NCSA claiming that massive > malicious requests from our dns. Just I want to understand how is > this possible massive attack towards the internet for deny requests. Those logs also show requests from another address in your own netblocks that's been assigned to a customer of Cyberia in Jeddah. That's in 212.119.73.32/27. Sten's explanation was almost certainly right with regards to the traffic seen or analysed by SA's national CERT. The traffic appearing to emanate from your DNS servers will be the result of the botnet or whatever it is making connections back to it's command and control host and spoofing the source addresses of the requests. The DNS resolvers can't tell the difference and reply to all the IPs a request appears to come from. Obviously you can't do anything about 212.76.76.18/32 directly, but if it's taken up this much time already then if I were in your position I'd just null route it at the border of Cyberia's network. Maybe notify Sahara Net that you've had to do it and forward them the same info SA's CERT gave you regarding their IP address. Meanwhile, one of your own customers (the one assigned that /27) need to hire an IT security consultant to clean their network. I'm assuming that log sample was just a quick cut and paste and there's actually a lot more. Search all the resolver logs for addresses in your IP space requesting that hostname and send all those customers a "your computer/network on IP $FOO has been compromised, you have X days to fix it or your connection will be suspended." Just warn your support staff before you do that because they're the ones who will receive the angry calls from confused accountants. Regards, Ben signature.asc Description: PGP signature ___ 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: Max slaves limit?
Mea culpa of the Windows process. I should have indicated that as well. Also I was remiss on not mentioning the MINIMAL-RESPONSES option in the discussion. It sounds like there are some newer options available under bind 9.11 and up (Thanks Mr. Andrews!) That's why I read this list. It's a great source of information. Thanks again. Best, Bob ___ 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
