similar to: [OT] DNSguruz pl help: whois structure, delegation & handling delegation with Tinydns.

On 4/21/2015 9:46 AM, John R. Dennison wrote: > On Tue, Apr 21, 2015 at 09:39:09AM -0700, John R Pierce wrote: >> >the whois command in c6 references whois.v6nic.net for ip addresses in the >> >43.0.0.0/8 range (and maybe others). v6nic is no longer a valid whois >> >server, any nets delegated to it should instead be delegated to apnic. > The distribution

the whois command in c6 references whois.v6nic.net for ip addresses in the 43.0.0.0/8 range (and maybe others). v6nic is no longer a valid whois server, any nets delegated to it should instead be delegated to apnic. i have no upstream connections... this change was made in the generic sources for jwhois some time ago I see this fix was introduced in F20 here,

This works for me on Centos 5.6. It may assist newcomers to the Linux world of Centos. whois 51.51.51.51 produces a normal and conventional display of data. However since ARIN, the North American registrar of IP addresses, "modernised" its WHOIS processing, a query to whois 64.64.64.64 will produce a one line summary of possible matches, which always includes ARIN, but omits the

On Tue, Apr 21, 2015 at 09:39:09AM -0700, John R Pierce wrote: > the whois command in c6 references whois.v6nic.net for ip addresses in the > 43.0.0.0/8 range (and maybe others). v6nic is no longer a valid whois > server, any nets delegated to it should instead be delegated to apnic. The distribution jwhosis.conf is hopelessly out-of-date. You can retrieve an up-to-date one from:

Hi, my name is Grant Taylor. I am a subscriber to the LARTC mail list lartc@mailman.ds9a.nl. The LARTC mail lists has been plagued with viral email coming from changing IPs in your one of your subnets. Based on the fact that the WhoIs information below says that the subnet in question is a dial up pool this would explain the changing IPs. In less than 6 days the list has received 14 viral

On Tue, 17 Jun 2014, John R Pierce wrote: > On 6/17/2014 9:36 PM, Devin Reade wrote: >> It looks like someone pooched a domain transfer, and the whois entry >> for centos.org is missing its NS records. I've sent an email to the >> whois tech contact @redhat, but I'm sending this to the list to hopefully >> bring it to someone else's attention, as well.

It looks like someone pooched a domain transfer, and the whois entry for centos.org is missing its NS records. I've sent an email to the whois tech contact @redhat, but I'm sending this to the list to hopefully bring it to someone else's attention, as well. Hopefully it gets gets out before my mailserver expires its DNS cache for centos.org. Expect centos.org to be offline for a bit

On 6/17/2014 9:36 PM, Devin Reade wrote: > It looks like someone pooched a domain transfer, and the whois entry > for centos.org is missing its NS records. I've sent an email to the > whois tech contact @redhat, but I'm sending this to the list to hopefully > bring it to someone else's attention, as well. > > Hopefully it gets gets out before my mailserver expires

I think this is probably my first post to this mailing list, so hello! Occasionally I log in to my servers from IP addresses without reverse DNS configured, so sometimes I'll see an IP I don't recognise because I can't remember what I did the day before and get a bit spooked until I WHOIS the IP and find the netname reminds me I logged in from that IP. I set out prepared to script

My home system has been hacked. It's running CentOS 4.4, and I recently added an account to play around with Samba shares to back up PCs here at home. I had set a weak password for that account and forgot to disable it after my testing. I could hear the disk being accessed constantly, so I knew something was up. I disabled the port forwarding to my CentOS box on my Linksys router

After reading this article: http://www.theregister.co.uk/2005/08/31/blocking_chinese_ip_addresses/ I got to thinking that there is really no reason for *any* traffic to hit my servers that comes from anywhere outside North America. So I wrote the perl script at the end of this posting to extract selected IP ranges posted at iana.org and convert them into iptables rules blocking any traffic

Hello listmates, Somehow or other my DNS services that are part of the ndjbdns-1.06-1.el7.x86_64 package would not start properly at startup. When I then start them up using systemctl: systemctl start dnscache systemctl start tinydns they start just fine. >From the log I got the following for tinydns: Oct 24 15:01:43 ns99 tinydns[1867]: tinydns: version 1.06: starting: Oct-24 2014 15:01:43

Hi all, tinydns starts up fine, selinux reports no issues (now after a day of clearing errors). If I turn selinux back to permissive in /etc/sysconfig/selinux, and reboot, tinydns responds to queries. If I turn selinux back to enforcing and reboot, tinydns does not respond. Monitoring /var/log/messages shows no errors from iptables/shorewall or selinux. The only way I can find an error is

Is there a tinydns or dns wizard that could give me some hints, please? I am setting up and testing tinydns, but have some problems figuring out how to route. I do get dnscache to listen on tinydns. Also I do not understand why it will not answer the given ip (127.0.0.1) to the name server. 1. Both services are up running and seems to be working fine, so why no reply, (on the first

I have used tinydns for many many years now and it has always worked very well. I like its simplicity: 1 text file is converted into a cdb database, there's no master/slave environment (all nameservers are equal) and synchronisation is done by rsync. Tinydns is run by runit, a supervise system. I'm looking at NSD now and I think I can use NSD the same way I use tinydns. The only

> Sorry - I once was sold on the idea of djb's tools and Qmail, and I've > regretted installing it ever since. Save yourself some serious agony - run > (don't walk!) away from djb-ANYTHING! I don't know what problems you had with it, but I'm hapilly using it on about 20 servers (both djbdns and qmail) and never had a problem with it. I'll remember your advice

Hi, Yes I aware to the NAT possibility, But let's assume that this is the issue, there is no reason that 30 listeners >From the same country will connect and disconnect at the same time range... I'm pretty sure that its individual listener/IP. I deleted the Access log files, but in the next time that I will catch similar situation again, I will complete the investigation. Nobody from

Good morning: We're about to start moving our public DNS to in-house managed servers. My first thought was "Linux + BIND" and we're done. Someone in another business unit's IT dept. has suggested tinydns be used. >From what I could find, it looks like this software hasn't really had any community drive behind it in a while. The latest RPMs on rpmforge are for red hat

On 6/16/15 1:09 AM, Nick Lewycky wrote: > Anirudh Sivaraman wrote: >> On Mon, Jun 15, 2015 at 10:50 AM, mats >> petersson<mats at planetcatfish.com> wrote: >>> It will iterate over the instructions in the order that they are >>> stored in >>> the module/function/basicblock that they belong to. And that SHOULD, >>> assuming llvm-dis does

On Mon, Jun 15, 2015 at 10:50 AM, mats petersson <mats at planetcatfish.com> wrote: > It will iterate over the instructions in the order that they are stored in > the module/function/basicblock that they belong to. And that SHOULD, > assuming llvm-dis does what it is expected to do, be the same order. > Thanks for the reply. What about instruction ordering across basic blocks?