The issue is only on my DNS server. I have a zone transfer from 44.in-addr.arpa and ampr.org, so a copy of the zones are located on my BIND server at 44.60.44.3
I've been using nslookup to look at the records from multiple machines. It only occurs on certain IPs where the fourth octet is less than 10.
I'll try dig as well.
- KB3VWG
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> [44net] Odd DNS Issue
> From:
> lleachii(a)aol.com
> Date:
> 10/10/2014 11:28 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> All,
>
> I'm wondering if anyone else has seen this issue. I'm running BIND version 9.9.5 at 44.60.44.3. I just recently upgraded from 9.8 because I thought it would solve a very weird issue that I'm experiencing.
>
> I allow all to to lookup 44.in-addr.arpa and ampr.org; and it works. BUT, some reverse records always time out.
I have seen this many times and never have been able to solve it. Some ampr.org DNS servers time out on some PTR records.
It comes and goes, can be OK for months and then come back.
When you focus on it to debug the issue it often disappears under your hands.
No idea what it is.
Rob
On 10/11/14, 10:31 AM, Brian wrote:
> Andy et al; On Sat, 2014-10-11 at 13:18 +0100, Andy Brittain wrote:
>>> I think opening up 44 net is potentially a good idea but then we run in
>>> to trouble where RF is involved. Would we not be passing traffic that
>>> technically doesn’t fit under our license t’s&c’s?
> Absolutely. That would easier open us up to pirating (why bother get a
> license if it's freely available?) and put us in jeopardy for possible
> violation of 3rd party communications regulations depending what the 3rd
> party does.
1. There is no guarantee that 44/8 traffic is sourced from licensed radio
amateurs.
2. There is no guarantee that 44/8 traffic is suitable for use over licensed
amateur radio frequencies in $REGULATORY_DOMAIN.
The only thing there is guaranteed about 44/8 is that is must be used for bona
fide amateur radio purposes. What these purposes are, is loosely defined and
open to interpretation.
Guys, it's just IP space. The sooner we separate networking from IP space,
the better IMO.
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
All,
I'm wondering if anyone else has seen this issue. I'm running BIND version 9.9.5 at 44.60.44.3. I just recently upgraded from 9.8 because I thought it would solve a very weird issue that I'm experiencing.
I allow all to to lookup 44.in-addr.arpa and ampr.org; and it works. BUT, some reverse records always time out.
So far, I have tested the following IP addresses which have PTR records, but do not produce results:
44.102.1.1
44.102.1.2
44.108.1.1
44.108.1.2
44.108.1.3
44.60.44.1
44.60.44.2
44.60.44.3
44.60.44.6
44.60.44.7
The only pattern that I've discovered when a lookup times out, is that the fourth octet is always less than 10. I've checked the system log, and there is no denial for the DSN query. I was wondering if anyone had ideas/suggestions.
Thanks and 73,
Lynwood
KB3VWG
Well I know this obviously, but we did get a 180 degree sector up on a
broadcast tower, so I have a bunch of newbies to microwave and
networking in general to deal with.
The consensus is to probably use the BBHN firmware as that is what the
Emcomm and not so tech guys will have a liking to.
So overall I don't think adding that kind of support to a ham rolled
firmware is a bad idea if someone out there had the urge to try and
figure it out. A few years back Ubiquiti AirOS supported those
frequencies natively. So one wonders if one day even Mikrotik might
have those features removed.
Speaking of BBHN is there any kind of video showing the more nuts and
bolts of it working for those of us who (or want to) understand
things a bit deeper?
A video that perhaps shows
broadband hamnet speed test (FTP transfer to a localhost, etc)
traceroutes to show hops when a node disappears or comes online
broadband hamnet route command output when a node disappears
Steve
---- Quote -----
If you want to get out of the part 15 jungle just use Mikrotik gear...
It won't run HSMM mesh but that's not a bad thing if you don't want
to pay the performance penalty of a mesh...
Bill
Atheros Chipset Radios are capable of operation between 2312-2732,
4920-6100 MHz. The purpose of this message is to hopefully draw a few
talented hams out of the wood work that can make a programming
contribution to an the existing Broadband Ham Network firmware
project.
You can look at how the ham radio frequency allocations overlap the
Part 15 bands here:
http://www.qsl.net/kb9mwr/projects/wireless/allocations.html
The Part 15 overlap where all consumer devices operate is heavily
crowded, and thusly the noise floor is high hampering long range links
that we as hams would like to establish. There are a couple third
party solutions to enable the extended frequency support to be able to
shift operations into the ham only portions of the bands. Neither of
them presently have native OLSR support in addition to the extended
frequency support. It would be highly desirable to see our own ham
firmware support the extended frequency support.
HSMM-Mesh / Broadband Hamnet Firmware
In the Fall of 2008, a group of amateurs from the Texas area announced
development of their own custom firmware for the WRT-54G to enable
HSMM-Mesh networking. This is the first ham specific firmware build.
It is also one of the first firmware builds to support OLSR, an ad-hoc
wireless mesh routing daemon. Initially this ham firmware build was
limited to the Linksys WRT54 series of wireless routers. In February
2014 the development team announced support for Ubiquiti 2.4 GHz
devices. In July 2014 support was extended to Ubiquiti 5 GHz
devices.
I should clarify that this firmware does not yet support non-part 15
channels, aka, extended channels / custom frequencies. Nor does it
yet support half-rate (10 MHz wide), or quarter-rate (5 MHz wide)
bandwidth channels to accompany use on ham only spectrum.
If you are knowledgeable with the Linux Kernel programming please
consider reaching out to the development team.
http://www.broadband-hamnet.org/download/firmware/
A discussion on the Broadband Hamnet / HSMM-Mesh ham firmware about
using channels outside of the Part 15 space:
http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-1113/t…
If we can develop the firmware that enables ham channels, Heikki
Hannikainen OH7LZB presented at the 2013 DCC a way to authenticate the
person who might like to download it is a ham.
http://www.youtube.com/watch?v=7anDmQQfyu8 Video presentation from the DCC
http://authtest.aprs.fi - authentication demo site
https://github.com/hessu/ham-cert-web-demo - Apache configuration and
PHP scripts
Greetings;
I have created a file at
http://n1uro.ampr.org/amprdns.brk
This file contains a ton of stray MX and CNAME records. If a coordinator
wishes to sort through it and clean up invalid entries, it's there.
--
73 de Brian Rogers - N1URO
email: <n1uro(a)n1uro.ampr.org>
Web: http://www.n1uro.net/
Ampr1: http://n1uro.ampr.org/
Ampr2: http://nos.n1uro.ampr.org
Linux Amateur Radio Services
axMail-Fax & URONode
AmprNet coordinator for:
Connecticut, Delaware, Maine,
Maryland, Massachusetts,
New Hampshire, Pennsylvania,
Rhode Island, and Vermont.
Greetings to everybody.
Following Shellshock...
There is another hole, called tmUnblock.cgi
targetted on some Cisco Linksys routers:
http://www.scip.ch/en/?vuldb.12362
More info on Internet, for instance:
http://security.stackexchange.com/questions/68405/what-is-tmunblock-cgi-and…
Even targeted at specific hardware, it is poking everywhere...
Short extract from my apache2.log
50.193.84.18 - - [05/Oct/2014:14:03:33 +0200] "GET /tmUnblock.cgi
HTTP/1.1" 400 518 "-" "-"
Best regards.
Tom - sp2lob
Hello Brian(N1URO) et al.
My list of "abusing" subnets and single IP's
contains 56 lines and still grows almost every day.
All of them blocked continuously by iptables.
For securing all amprnet interfaces I have one PERFECT cure:
-A INPUT ! -s 44.0.0.0/8 -i tunl0 -j DROP
-A INPUT ! -s 44.0.0.0/8 -i tun0 -j DROP
-A INPUT ! -s 44.0.0.0/8 -i tun1 -j DROP
-A INPUT ! -s 44.0.0.0/8 -i tun2 -j DROP
-A INPUT ! -s 44.0.0.0/8 -i sl0 -j DROP
-A INPUT ! -s 44.0.0.0/8 -i sl1 -j DROP
-A INPUT ! -s 44.0.0.0/8 -i sl2 -j DROP
Really deadly weapon, Hi!
Nothing, literally nothing, what isn't originated
from 44 network is explicitly DROPped.
JNOS-2.0j4, TNOS-2.40, OpenVPN(44net), TNOS-3.01a1
and two (X)net's are as safe as never before.
Sending email to the "abuse" mailbox is nice and pollite
way but do not change situation right away.
Just my personal point of view...
One day somebody said: if I run taxi business, say in Texas,
I do not want customer from LaLaLand poking around!
Best regards.
Tom - sp2lob
Send from Sony Xperia Z1
http://www.aqua-mail.com
Tom,
I am also using Fail2BAN.
I created my own jail for JNOS and it works great.
That is also why I needed to change the JNOS log file name to something
static. That way I could avoid having to reload/restart Fail2Ban every
morning at midnight to look for a new log.
If you need the Jail regex I created for JNOS (assuming you're using JNOS),
contact me off-list (kg6baj(a)n1oes.org) and I can email it to you.
Bill
KG6BAJ
At 09:13 AM 09/29/14, you wrote:
>I do this with a program called fail2ban. You configure it to watch
>log files for authentication failures or other suspicious activity. It
>then blocks the suspicious source IP in iptables for the configured
>period of time. When the time expires, the IP is unbanned, so false
>positives or new users of an IP address aren't adversely affected.
>
>I get many bans per day and don't put much energy into monitoring or
>reporting them.
>
>Tom KD7LXL
>_________________________________________
