Re: [HamWAN PSDR] AMPRnet tunnel outage
Resent with my correct eMail address ... On 2014-04-10 18:56, Dean Gibson wrote:
On 2014-04-10 18:27, Bart Kus wrote:
....
/>traceroute 44.24.240.173 traceroute to 44.24.240.173 (44.24.240.173), 30 hops max, 38 byte packets 1 209.59.211.184 (209.59.211.184) 0.172 ms 0.075 ms 0.062 ms ... 17 44.24.242.19 (44.24.242.19) 95.778 ms 98.257 ms 95.279 ms 18 44.24.242.10 (44.24.242.10) 142.098 ms 103.353 ms 148.017 ms 19 44.24.240.132 (44.24.240.132) 137.942 ms 112.522 ms 113.787 ms 20 * * * 21 * * */
Nope, that shouldn't be. The network correctly routed your packets to the right sector @ Paine, and then failed on the very last hop in communicating with your modem? Depending on where the trace was originating from and the state of your modem's routing table at the time, your modem may have had different ideas about how to reply. Or, you might have been disconnected at the time?
Where are these following traces from? The modem? Was there a specific source IP used?
The trace came from my computer on the Internet at 209.59.217.159, with the exact command you see above. Are you sure that 44.24.240.132 is the right sector? Everything I see comes from 44.24.240.161. Note (not included above but in my previous message) that I can traceroute to .132 OK, but attempting to go any further back in the inbound traceroute list, seems to repeat a HamWAN IP address and then *stop*. The modem was on, I was monitoring it with */interface wireless monitor 0*, and the "last-ip" field never changed (as it usually does on an attempted access).
When I post my various messages, none of them are at all urgent, but I like to post "anomalies" if they are of help in administration. I'm just experimenting.
On 04/10/2014 06:57 PM, Dean Gibson AE7Q wrote:
Resent with my correct eMail address ...
On 2014-04-10 18:56, Dean Gibson wrote:
On 2014-04-10 18:27, Bart Kus wrote:
....
/>traceroute 44.24.240.173 traceroute to 44.24.240.173 (44.24.240.173), 30 hops max, 38 byte packets 1 209.59.211.184 (209.59.211.184) 0.172 ms 0.075 ms 0.062 ms ... 17 44.24.242.19 (44.24.242.19) 95.778 ms 98.257 ms 95.279 ms 18 44.24.242.10 (44.24.242.10) 142.098 ms 103.353 ms 148.017 ms 19 44.24.240.132 (44.24.240.132) 137.942 ms 112.522 ms 113.787 ms 20 * * * 21 * * */
Nope, that shouldn't be. The network correctly routed your packets to the right sector @ Paine, and then failed on the very last hop in communicating with your modem? Depending on where the trace was originating from and the state of your modem's routing table at the time, your modem may have had different ideas about how to reply. Or, you might have been disconnected at the time?
Where are these following traces from? The modem? Was there a specific source IP used?
The trace came from my computer on the Internet at 209.59.217.159, with the exact command you see above. Are you sure that 44.24.240.132 is the right sector?
Yes, absolutely sure: [eo@Paine-s2] > /ip address print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 ;;; default configuration 44.24.240.132/28 44.24.240.128 ether1-local 1 44.24.240.161/28 44.24.240.160 wlan1-gateway The modem has 2 interfaces, so 2 IPs. Which IP you see along the trace depends on the direction your trace is taking.
Everything I see comes from 44.24.240.161. Note (not included above but in my previous message) that I can traceroute to .132 OK, but attempting to go any further back in the inbound traceroute list, seems to repeat a HamWAN IP address and then *stop*. The modem was on, I was monitoring it with */interface wireless monitor 0*, and the "last-ip" field never changed (as it usually does on an attempted access).
Can you show your modem's routing table and firewall here? (/ip route export; /ip firewall export)
When I post my various messages, none of them are at all urgent, but I like to post "anomalies" if they are of help in administration. I'm just experimenting.
That's cool, the bug-finding is appreciated. Although in this case, I suspect it's on your end. --Bart
Errr, that should say "/ip route print" instead, to show dynamic routes. Also, you can engage the /tool sniffer quick to check for your traceroute making it into your modem, just as you did before with the routing issue. I wouldn't count on "last-ip" being an accurate representation, it's just a random sampling of taffic and can miss packets. --Bart On 04/10/2014 07:03 PM, Bart Kus wrote:
On 04/10/2014 06:57 PM, Dean Gibson AE7Q wrote:
Resent with my correct eMail address ...
On 2014-04-10 18:56, Dean Gibson wrote:
On 2014-04-10 18:27, Bart Kus wrote:
....
/>traceroute 44.24.240.173 traceroute to 44.24.240.173 (44.24.240.173), 30 hops max, 38 byte packets 1 209.59.211.184 (209.59.211.184) 0.172 ms 0.075 ms 0.062 ms ... 17 44.24.242.19 (44.24.242.19) 95.778 ms 98.257 ms 95.279 ms 18 44.24.242.10 (44.24.242.10) 142.098 ms 103.353 ms 148.017 ms 19 44.24.240.132 (44.24.240.132) 137.942 ms 112.522 ms 113.787 ms 20 * * * 21 * * */
Nope, that shouldn't be. The network correctly routed your packets to the right sector @ Paine, and then failed on the very last hop in communicating with your modem? Depending on where the trace was originating from and the state of your modem's routing table at the time, your modem may have had different ideas about how to reply. Or, you might have been disconnected at the time?
Where are these following traces from? The modem? Was there a specific source IP used?
The trace came from my computer on the Internet at 209.59.217.159, with the exact command you see above. Are you sure that 44.24.240.132 is the right sector?
Yes, absolutely sure:
[eo@Paine-s2] > /ip address print Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 ;;; default configuration 44.24.240.132/28 44.24.240.128 ether1-local 1 44.24.240.161/28 44.24.240.160 wlan1-gateway
The modem has 2 interfaces, so 2 IPs. Which IP you see along the trace depends on the direction your trace is taking.
Everything I see comes from 44.24.240.161. Note (not included above but in my previous message) that I can traceroute to .132 OK, but attempting to go any further back in the inbound traceroute list, seems to repeat a HamWAN IP address and then *stop*. The modem was on, I was monitoring it with */interface wireless monitor 0*, and the "last-ip" field never changed (as it usually does on an attempted access).
Can you show your modem's routing table and firewall here? (/ip route export; /ip firewall export)
When I post my various messages, none of them are at all urgent, but I like to post "anomalies" if they are of help in administration. I'm just experimenting.
That's cool, the bug-finding is appreciated. Although in this case, I suspect it's on your end.
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On 2014-04-10 19:06, Bart Kus wrote:
Errr, that should say "/ip route print" instead, to show dynamic routes.
Also, you can engage the /tool sniffer quick to check for your traceroute making it into your modem, just as you did before with the routing issue. I wouldn't count on "last-ip" being an accurate representation, it's just a random sampling of taffic and can miss packets.
--Bart
/> /tool sniffer quick ip-address=!192.168.0.0/16 INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS ether1... 6.013 7 <- 169.254.1.227:56918 ether1... 6.021 8 <- 169.254.1.38:47040 wlan1-... 6.387 9 <- 209.59.217.159:41540 wlan1-... 8.302 10 <- 44.24.240.161 wlan1-... 8.454 11 <- 0.0.0.0:68 (bootpc) wlan1-... 11.117 12 <- 0.0.0.0:68 (bootpc) wlan1-... 11.4 13 <- 209.59.217.159:41540 ether1... 12.048 14 <- 169.254.1.38:21302 ether1... 12.079 15 <- 169.254.1.38:7500 wlan1-... 12.885 16 <- 44.24.240.161:5678 (discovery) wlan1-... 12.888 17 <- fe80::d6ca:6dff:fe7a:b807:5678 (... wlan1-... 14.246 18 <- 0.0.0.0:68 (bootpc) wlan1-... 16.06 19 <- 0.0.0.0:68 (bootpc) wlan1-... 16.452 20 <- 209.59.217.159:41540 wlan1-... 18.311 21 <- 44.24.240.161 wlan1-... 19.865 22 <- 0.0.0.0:68 (bootpc) wlan1-... 21.465 23 <- 209.59.217.159:41540 ether1... 22.061 24 <- 169.254.1.227:56918 ether1... 22.068 25 <- 169.254.1.38:47040 ether1... 22.138 26 <- 169.254.1.38:7500 / OK, you're correct; it *is* getting through ...
On 2014-04-10 19:03, Bart Kus wrote: > > Yes, absolutely sure: Ok, just checking > Can you show your modem's routing table and firewall here? (/ip route > print; /ip firewall export) > /ip route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADS 0.0.0.0/0 44.24.240.161 1 1 ADC 44.24.240.160/28 44.24.240.173 wlan1-gateway 0 2 ADC 192.168.0.0/18 192.168.3.251 ether1-local 0 > /ip firewall export # apr/10/2014 19:20:59 by RouterOS 6.10 # software id = LTNR-CTND # /ip firewall filter add chain=input comment="default configuration" protocol=icmp add chain=input comment="default configuration" connection-state=established add chain=input comment="default configuration" connection-state=related add chain=input dst-port=53 in-interface=wlan1-gateway protocol=udp add chain=input dst-port=53,80 in-interface=wlan1-gateway protocol=tcp add action=drop chain=input comment="default configuration" in-interface=wlan1-gateway add chain=forward comment="default configuration" connection-state=established add chain=forward comment="default configuration" connection-state=related add chain=forward dst-port=53 in-interface=wlan1-gateway protocol=udp add chain=forward dst-port=53,80 in-interface=wlan1-gateway protocol=tcp add action=drop chain=forward comment="default configuration" connection-state=invalid /ip firewall mangle add action=change-mss chain=output new-mss=1378 protocol=tcp tcp-flags=syn tcp-mss=!0-1378 add action=change-mss chain=forward new-mss=1378 protocol=tcp tcp-flags=syn tcp-mss=!0-1378 /ip firewall nat add action=masquerade chain=srcnat comment="default configuration" out-interface=wlan1-gateway to-addresses=0.0.0.0 add action=masquerade chain=srcnat dst-port=53 out-interface=ether1-local protocol=udp to-addresses=192.168.0.250 add action=masquerade chain=srcnat dst-port=53,80 out-interface=ether1-local protocol=tcp to-addresses=192.168.0.250 add action=dst-nat chain=dstnat dst-port=53 in-interface=wlan1-gateway protocol=udp to-addresses=192.168.0.250 add action=dst-nat chain=dstnat dst-port=53,80 in-interface=wlan1-gateway protocol=tcp to-addresses=192.168.0.250 Happy hunting ...
On 04/10/2014 07:23 PM, Dean Gibson AE7Q wrote:
add action=drop chain=input comment="default configuration" in-interface=wlan1-gateway My money is on that rule killing the inbound traceroute packets before the router can formulate a response packet.
--Bart
Dean, Have you tried using a traceroute -I to use ICMP for the traceroute? A default traceroute will choose random UDP ports at the destination, so your firewall rules WILL kill those. I would suspect an ICMP based traceroute would work. Nigel On Apr 10, 2014, at 7:34 PM, Bart Kus <me@bartk.us> wrote:
On 04/10/2014 07:23 PM, Dean Gibson AE7Q wrote:
add action=drop chain=input comment="default configuration" in-interface=wlan1-gateway My money is on that rule killing the inbound traceroute packets before the router can formulate a response packet.
--Bart
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
On 2014-04-10 19:34, Bart Kus wrote:
On 04/10/2014 07:23 PM, Dean Gibson AE7Q wrote:
add action=drop chain=input comment="default configuration" in-interface=wlan1-gateway My money is on that rule killing the inbound traceroute packets before the router can formulate a response packet.
--Bart
OK, problem solved: Actually, the root problem was that the following didn't work, and I was using traceroute (to my actual HamWAN IP address) to try to resolve it: /lynx http://ns1.ae7q.ampr.*n**et*/ Note that /host ns1.ae7q.ampr.net/ resolves any address ending in ampr.net, hiding the problem ... What was supposed to work was: / ////lynx http://ns1.ae7q.ampr.*org*/ And that does work ... Sorry for the false alarm ... A WHOIS on ampr.net shows the domain for sale ... (my opinion on this is self-censored).
Two days ago I obtained domain 44rf.net, for the sole purpose of supporting amateurs on 44.x.x.x which need more *subdomain* support than ampr.org provides (ie, *none*; Brian Kantor will not allow NS records in ampr.org). It's trivial to allow subdomains of 44rf.net which users can *self-manage*, without screwing up the parent domain (volunteers/testers welcome). And, with the use of stub zones, I support (present tense) referrals to ampr.org, hamwan.net, and other domains in a situation where the root servers are not available. Eg:
dig @ns1.ae7q.ampr.org db0bi.ampr.org
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org db0bi.ampr.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55750 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 10 ;; QUESTION SECTION: ;db0bi.ampr.org. IN A ;; ANSWER SECTION: db0bi.ampr.org. 3568 IN A 44.225.61.14 ;; AUTHORITY SECTION: ampr.org. 3568 IN NS hamradio.ucsd.edu. ampr.org. 3568 IN NS ns0.comgw.net. ampr.org. 3568 IN NS ns1.defaultroute.net. ampr.org. 3568 IN NS ns2.threshinc.com. ampr.org. 3568 IN NS ampr.org. ampr.org. 3568 IN NS munnari.OZ.AU. ampr.org. 3568 IN NS ampr-dns.in-berlin.de. ;; ADDITIONAL SECTION: ns1.defaultroute.net. 172764 IN A 74.120.14.69 ns2.threshinc.com. 3564 IN A 192.41.222.8 ns2.threshinc.com. 172764 IN AAAA 2604:5000:0:2::2 ampr.org. 3568 IN A 44.0.0.1 munnari.OZ.AU. 14365 IN A 202.29.151.3 munnari.OZ.AU. 86364 IN AAAA 2001:3c8:9007:1::21 munnari.OZ.AU. 86364 IN AAAA 2001:3c8:9009:181::2 ampr-dns.in-berlin.de. 864 IN A 192.109.42.4 ampr-dns.in-berlin.de. 864 IN AAAA 2a01:238:4073:e600::1 hamradio.ucsd.edu. 43164 IN A 169.228.66.6 ;; Query time: 253 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 20:10:06 2014 ;; MSG SIZE rcvd: 452
dig @ns1.ae7q.ampr.org a.ns.hamwan.net
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org a.ns.hamwan.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;a.ns.hamwan.net. IN A ;; ANSWER SECTION: a.ns.hamwan.net. 3600 IN A 44.24.244.2 ;; AUTHORITY SECTION: hamwan.net. 172800 IN NS a.ns.hamwan.net. hamwan.net. 172800 IN NS b.ns.hamwan.net. ;; Query time: 499 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 20:31:47 2014 ;; MSG SIZE rcvd: 79 However, notice what happens when I access a domain for which I do *not* have a stub zone declaration:
dig @ns1.ae7q.ampr.org www.hamwan.org
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org www.hamwan.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24283 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.hamwan.org. IN A ;; AUTHORITY SECTION: . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. ;; Query time: 258 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 22:11:09 2014 ;; MSG SIZE rcvd: 243 That is, ns1.ae7q.ampr.org does not function as a general-purpose recursive DNS server. Now, if someone else is already doing this ... let me know.
I don't get the point of a recursive DNS server that by default doesn't resolve the Internet. Also, we offer recursive DNS services already on 44.24.244.1 and 44.24.245.1. These include recursive services for *.HamWAN.net in the absence of root servers, as well as reverse DNS for our IP ranges, also available in the absence of root servers. The access to the recursive services is limited to 44-net clients. On the authoritative side, we're happy to delegate sub-zones. *.AE7Q.HamWAN.net for example can be delegated. While Brian does offer some support for DNS on ampr.org, but I do think AMPR needs to support reverse DNS delegation. And DNSSEC. I'm not sure why delegations aren't allowed. I know it's come up before. --Bart On 4/10/2014 10:21 PM, Dean Gibson AE7Q wrote:
Two days ago I obtained domain 44rf.net, for the sole purpose of supporting amateurs on 44.x.x.x which need more *subdomain* support than ampr.org provides (ie, *none*; Brian Kantor will not allow NS records in ampr.org). It's trivial to allow subdomains of 44rf.net which users can *self-manage*, without screwing up the parent domain (volunteers/testers welcome). And, with the use of stub zones, I support (present tense) referrals to ampr.org, hamwan.net, and other domains in a situation where the root servers are not available. Eg:
dig @ns1.ae7q.ampr.org db0bi.ampr.org
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org db0bi.ampr.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55750 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 10
;; QUESTION SECTION: ;db0bi.ampr.org. IN A
;; ANSWER SECTION: db0bi.ampr.org. 3568 IN A 44.225.61.14
;; AUTHORITY SECTION: ampr.org. 3568 IN NS hamradio.ucsd.edu. ampr.org. 3568 IN NS ns0.comgw.net. ampr.org. 3568 IN NS ns1.defaultroute.net. ampr.org. 3568 IN NS ns2.threshinc.com. ampr.org. 3568 IN NS ampr.org. ampr.org. 3568 IN NS munnari.OZ.AU. ampr.org. 3568 IN NS ampr-dns.in-berlin.de.
;; ADDITIONAL SECTION: ns1.defaultroute.net. 172764 IN A 74.120.14.69 ns2.threshinc.com. 3564 IN A 192.41.222.8 ns2.threshinc.com. 172764 IN AAAA 2604:5000:0:2::2 ampr.org. 3568 IN A 44.0.0.1 munnari.OZ.AU. 14365 IN A 202.29.151.3 munnari.OZ.AU. 86364 IN AAAA 2001:3c8:9007:1::21 munnari.OZ.AU. 86364 IN AAAA 2001:3c8:9009:181::2 ampr-dns.in-berlin.de. 864 IN A 192.109.42.4 ampr-dns.in-berlin.de. 864 IN AAAA 2a01:238:4073:e600::1 hamradio.ucsd.edu. 43164 IN A 169.228.66.6
;; Query time: 253 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 20:10:06 2014 ;; MSG SIZE rcvd: 452
dig @ns1.ae7q.ampr.org a.ns.hamwan.net
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org a.ns.hamwan.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION: ;a.ns.hamwan.net. IN A
;; ANSWER SECTION: a.ns.hamwan.net. 3600 IN A 44.24.244.2
;; AUTHORITY SECTION: hamwan.net. 172800 IN NS a.ns.hamwan.net. hamwan.net. 172800 IN NS b.ns.hamwan.net.
;; Query time: 499 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 20:31:47 2014 ;; MSG SIZE rcvd: 79
However, notice what happens when I access a domain for which I do *not* have a stub zone declaration:
dig @ns1.ae7q.ampr.org www.hamwan.org
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org www.hamwan.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24283 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION: ;www.hamwan.org. IN A
;; AUTHORITY SECTION: . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET.
;; Query time: 258 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 22:11:09 2014 ;; MSG SIZE rcvd: 243
That is, ns1.ae7q.ampr.org does not function as a general-purpose recursive DNS server.
Now, if someone else is already doing this ... let me know.
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org
The idea is (see the penultimate line in prior message) for the 44rf.net DNS to *not* be recursive, but just provide referrals. The point is to have access to other domains (at least DNS lookup) outside of 44.24.240.0/20, in situations where Internet access isn't available. Now, admittedly the probability of that is low, and probably even lower that if Internet access wasn't available, that 44.x.x.x addresses outside of 44.24.240.0/20 served up by 44rf.net servers would be accessible (ie, that you'd have network connectivity to those addresses). But, it's cheap experiment. Opinions as to why this might be a dumb idea, are accepted ... Further, getting the domain allowed me to find out that my domain (EnCirca) registrar, which used to be competent, is now completely and utterly *incompetent*. I will be transferring my ten domains to another registrar, as soon as I've found one at a competitive price that provides DNS servers that can be used as slaves to a customer master DNS machine. Previously, I used DomainMonger, which provided this capability for years, but their prices seem a little high. EnCirca has it, but alas, something is wrong there, as I have had over a dozen eMails back and forth over the last two days, just to get capability working again that worked a year ago. Yes, I wouldn't mind a delegation of ae7q.hamwan.net. Question: would that allow me to make changes on my own, or can I do that myself after delegation is set up? With BIND, there are two ways to do it: 1. Actual delegation (a separate zone with a separate nameserver, maintained on my server). 2. Where the subdomains are maintained on the main domain's DNS server, and the DDNS (restricted to modifications that match a subdomain pattern) is used to modify the zone. I was planning on offering both for 44rf.net. In a later message I'll discuss my request to Brian Kantor for subdomain delegation, and his response. On 2014-04-10 23:19, Bart Kus wrote:
I don't get the point of a recursive DNS server that by default doesn't resolve the Internet.
Also, we offer recursive DNS services already on 44.24.244.1 and 44.24.245.1. These include recursive services for *.HamWAN.net in the absence of root servers, as well as reverse DNS for our IP ranges, also available in the absence of root servers. The access to the recursive services is limited to 44-net clients.
On the authoritative side, we're happy to delegate sub-zones. *.AE7Q.HamWAN.net for example can be delegated.
While Brian does offer some support for DNS on ampr.org, but I do think AMPR needs to support reverse DNS delegation. And DNSSEC. I'm not sure why delegations aren't allowed. I know it's come up before.
--Bart
On 4/10/2014 10:21 PM, Dean Gibson AE7Q wrote:
Two days ago I obtained domain 44rf.net, for the sole purpose of supporting amateurs on 44.x.x.x which need more *subdomain* support than ampr.org provides (ie, *none*; Brian Kantor will not allow NS records in ampr.org). It's trivial to allow subdomains of 44rf.net which users can *self-manage*, without screwing up the parent domain (volunteers/testers welcome). And, with the use of stub zones, I support (present tense) referrals to ampr.org, hamwan.net, and other domains in a situation where the root servers are not available. Eg:
dig @ns1.ae7q.ampr.org db0bi.ampr.org
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org db0bi.ampr.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55750 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 10
;; QUESTION SECTION: ;db0bi.ampr.org. IN A
;; ANSWER SECTION: db0bi.ampr.org. 3568 IN A 44.225.61.14
;; AUTHORITY SECTION: ampr.org. 3568 IN NS hamradio.ucsd.edu. ampr.org. 3568 IN NS ns0.comgw.net. ampr.org. 3568 IN NS ns1.defaultroute.net. ampr.org. 3568 IN NS ns2.threshinc.com. ampr.org. 3568 IN NS ampr.org. ampr.org. 3568 IN NS munnari.OZ.AU. ampr.org. 3568 IN NS ampr-dns.in-berlin.de.
;; ADDITIONAL SECTION: ns1.defaultroute.net. 172764 IN A 74.120.14.69 ns2.threshinc.com. 3564 IN A 192.41.222.8 ns2.threshinc.com. 172764 IN AAAA 2604:5000:0:2::2 ampr.org. 3568 IN A 44.0.0.1 munnari.OZ.AU. 14365 IN A 202.29.151.3 munnari.OZ.AU. 86364 IN AAAA 2001:3c8:9007:1::21 munnari.OZ.AU. 86364 IN AAAA 2001:3c8:9009:181::2 ampr-dns.in-berlin.de. 864 IN A 192.109.42.4 ampr-dns.in-berlin.de. 864 IN AAAA 2a01:238:4073:e600::1 hamradio.ucsd.edu. 43164 IN A 169.228.66.6
;; Query time: 253 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 20:10:06 2014 ;; MSG SIZE rcvd: 452
dig @ns1.ae7q.ampr.org a.ns.hamwan.net
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org a.ns.hamwan.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION: ;a.ns.hamwan.net. IN A
;; ANSWER SECTION: a.ns.hamwan.net. 3600 IN A 44.24.244.2
;; AUTHORITY SECTION: hamwan.net. 172800 IN NS a.ns.hamwan.net. hamwan.net. 172800 IN NS b.ns.hamwan.net.
;; Query time: 499 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 20:31:47 2014 ;; MSG SIZE rcvd: 79
However, notice what happens when I access a domain for which I do *not* have a stub zone declaration:
dig @ns1.ae7q.ampr.org www.hamwan.org
; <<>> DiG 9.2.4 <<>> @ns1.ae7q.ampr.org www.hamwan.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24283 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 0
;; QUESTION SECTION: ;www.hamwan.org. IN A
;; AUTHORITY SECTION: . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET.
;; Query time: 258 msec ;; SERVER: 44.24.240.173#53(44.24.240.173) ;; WHEN: Thu Apr 10 22:11:09 2014 ;; MSG SIZE rcvd: 243
That is, ns1.ae7q.ampr.org does *not* function as a general-purpose recursive DNS server.
Now, if someone else is already doing this ... let me know.
On Thu, Apr 10, 2014 at 11:19 PM, Bart Kus <me@bartk.us> wrote:
I don't get the point of a recursive DNS server that by default doesn't resolve the Internet.
A major reason is DNS amplification attacks which is a form of DDoS.
participants (4)
-
Bart Kus -
Dean Gibson AE7Q -
Don Fanning -
Nigel Vander Houwen