- Roundtable - muug.ca

IPv6 tunnels, Netflix, and AAAA records (was help! dns zone delegation wonky for AAAA)
by Theodore Baschak 25 Nov '16

25 Nov '16

> On Nov 24, 2016, at 3:54 AM, Trevor Cordes <trevor(a)tecnopolis.ca> wrote: > > First I found this named option: > filter-aaaa-on-v4 (and -v6) > "It is intended to help the transition from IPv4 to IPv6 by not giving > IPv6 addresses to DNS clients unless they have connections to the IPv6 > Internet." > Super description and chart here: > https://kb.isc.org/article/AA-00576/0/Filter-AAAA-option-in-BIND-9-.html <https://kb.isc.org/article/AA-00576/0/Filter-AAAA-option-in-BIND-9-.html> This came up recently for me in another discussion. As an IPv6 pioneer, I'm fully IPv6 enabled and have been for the last 10 years or so. At some points that has been over HE.net IPv6 tunnels, and more recently that has been native IPv6 access. As I'm my own ISP, and I do my own BGP for myself, the address ranges I use for myself are properly registered and located in Winnipeg, Manitoba so I don't have any issues running Netflix with their latest "war on tunnels". However, for people who have a HE.net IPv6 tunnel (very very common), which has IPv6 space which is registered in the US, this causes issues with netflix when requests start cross countries of apparent origin. One of the solutions I found that worked quite nicely was to run a separate recursive DNS server for netflix users that had the filter-aaaa-on-* options enabled. Queries for netflix domains are then routed to this DNS server that strips out the AAAA records so that netflix runs only over the IPv4 connection, originating from a Canadian IP keeping netflix happy. Theodore Baschak - AS395089 - Hextet Systems https://ciscodude.net/ - https://hextet.systems/ http://mbix.ca/

1 0

New O'Reilly Humble Bundle of books!
by Trevor Cordes 25 Nov '16

25 Nov '16

Just like they did with No Starch Press, Humble Bundle has just offerred a new O'Reilly bundle with (up to) 16 *NIX ebooks for as little as $15 US$. Not bad. None are their newest titles, but there's still a lot of good stuff in there. And we all know that with *NIX most things don't go obsolete. If my math is on target, you have until Dec 7-ish to act on this. As with the NSP bundle, MUUG will be purchasing one bundle for DP giveaways. (And I'll be buying a set for myself too, though like many of you I already have around half of them on paper!) Thanks to Adam for originally spotting this. ==== Humble Bundle Get a library of O'Reilly ebooks and support charity You're not a Unix, are you? + 15 more great reference books from our friends at O'Reilly! https://www.humblebundle.com/books/unix-book-bundle

1 0

mailing list error
by Trevor Cordes 25 Nov '16

25 Nov '16

Apologies, but the MUUG mailing lists may have delayed/deferred (or even dropped) emails to a very small subset of members since the mailman migration in the last 2 weeks. If this applies to you you would not have received any muug mailing list emails during this time. Some of them may have just come through to you as I have now fixed the problem. Ones over 5 days (or so) probably got dropped. If you want to see the emails you may have missed, you can view them in the web interface: https://muug.ca/pipermail/roundtable/2016-November/date.html This problem only affected people who have mail servers that a) have STARTTLS enabled, *and* b) have their servers set to only allow obsolete encryption methods. If you can update your mail server to the latest version you will be less likely to have this problem in the future with other email senders. This problem will not occur on the muug lists again because I have disabled opportunistic muug-as-client smtp encryption. For those interested, the latest sendmail (which we may not be able to upgrade to for quite a long time) has an option to fallback to non-encrypted when the initial encrypted connection attempt fails. That would solve this problem more cleanly on the muug side. Not sure why this wasn't the default or available in sendmail the whole time, as the "encrypt or bust" paradigm we're stuck with in v8.14 is lame. No worries though, as 99% of the net still happily doesn't TLS smtp. It's more gravy than anything.

1 0

help! dns zone delegation wonky for AAAA
by Trevor Cordes 24 Nov '16

24 Nov '16

I'm seeing some weird behaviour related to AAAA and delegation I'd like to correct with a BIND DNS setup. I have no AAAA records anywhere. Some lookup tools/libraries insist on looking up AAAA, I want them to fail immediately. All servers/clients involved are run with the -4 option to run all traffic over IPv4. The problem is that I'm seeing occassional lookup delays for AAAA records on some boxes (the ones that delegate), but not other ones (every other box). On my box (BOX1) I'm authoritative for foo.com (only for my internal networks). On the same box, I delegate sub.foo.com to ns.com (BOX2). BOX2 is authoritative for foo.com and sub.foo.com. I do this so BOX1 can have local dynamic DNS for local Windows boxes, etc, on foo.com. Whereas the BOX2 view is for the whole world, to which I don't want to share the existence of windows.foo.com, etc. A bit messy, but this has worked for me for 15 years. The problem symptoms: I run "host bar.sub.foo.com " on the boxes: BOX1: bar.sub.foo.com has address 1.2.3.4 Host bar.sub.foo.com not found: 2(SERVFAIL) bar.sub.foo.com mail is handled by 5 bar.sub.foo.com. <often delays 5-10sec before giving the SERVFAIL BOX2 (and every other box in the world except BOX1!!): bar.sub.foo.com has address 1.2.3.4 bar.sub.foo.com mail is handled by 5 bar.sub.foo.com. I don't want the delay or the SERVFAIL on BOX1. The host command by default does a lookup of AA, AAAA and MX in that order. That's fine. But I want them all to run without delay, and the AAAA to be ignored like it is on BOX2. Again, there are no AAAA records in any of these zone files. I think I'm seeing the precise bug discussed here: https://tools.ietf.org/html/draft-ietf-dnsop-misbehavior-against-aaaa-00 search to: 4.4 Make Lame Delegation That document doesn't seem to provide any solutions. I think the issue is when BOX2 (or any box but BOX1) does a lookup, it checks only with BOX2, sees there's no AAAA and happily ignores AAAA. I think in essence it's like "I'm BOX2, I'm authoritative and I have no AAAA". host is happy with this. With BOX1, it does a lookup with BOX1's named which recurses out to the delegation on BOX2. BOX2 says the same as it did above, but this time it's talking to BOX1 named, not the host command. BOX1 named must be saying "I thought BOX2 was authoritative, but I find no AAAA so it's not authoritative after all, and I don't know anyone who is so I'm spewing this error SERVFAIL". I'm just guessing here. I want the host command on BOX1 to behave the same as BOX2. Can it be done? I actually was seeing the exact same problem with the nonexistent bar.sub.foo.com MX record and I solved it by adding an MX record for it on BOX2. However, I don't want any AAAA record on any box, as none of them have IPv6 addresses! Surely there must be a solution to this weird problem. Possibly relevant is how dig behaves with different usage: BOX1#dig -tAAAA @localhost bar.sub.foo.com ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2619 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;bar.sub.foo.com. IN AAAA BOX1#dig -tAAAA @ns.com bar.sub.foo.com ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5477 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;bar.sub.foo.com. IN AAAA ;; AUTHORITY SECTION: foo.com. 86400 IN SOA ns.com. 17 1800 300 604800 86400 BOX2#dig -tAAAA @localhost bar.sub.foo.com **pretty much the same output as above 2nd example, NOERROR** BOX2#dig -tAAAA @ns.com bar.sub.foo.com **pretty much the same output as above 2nd example, NOERROR** It's that SERVFAIL in example dig #1 above that I want to eliminate, and thus also the SERVFAIL with host. Thanks!

3 7

home network hangs up when ISP diconnected
by c0l0nelFlagg 24 Nov '16

24 Nov '16

My apologies for the previous reply post to ask this new question. I have a home network that appears to stop working whenever the ISP connection to the outside world is dropped. I am not sure why or how to remedy it which is why I am posting here. I have 5 linux workstations on the internal network 3 MINT 18, 1 XUbuntu, and 1 UbuntuStudio all the latest versions. 3 of the workstations (all MINT ones dual boot to Win 7 Pro as well). I also have a dedicated Ubuntu server on the network (also the latest Ubuntu version). The ISP connection (being in a rural area) is a cellular voice/data hub. The data connection from the hub feeds the hot or RED NIC input to the dedicated firewall machine Smoothwall Express. The GREEN or LAN side output from the Smoothwall machine then feeds a couple of Gigabit Ethernet smartswitches connecting to the network workstations, server, and smart TV's and Canon MP620 networked printer. The Smoothwall dhcp server capabilities are set up to assign IPv4 addresses to each permanently connected LAN device with a reserved IPv4 address based on the device's MAC address. All network devices have the Smoothwall specified as the 1st dns address as well as gateway device. The second dns device is the IPv4 address assigned to the ISP voice data hub which is the gateway for the smoothwall machine. A third alt dns address is Google's public dns at 8.8.8.8. Under normal serviceable connections, all is well, however if I lose the ISP connection everything running linux appears to get bogged down as if it was waiting for long timeouts of some sort; and if win 7 Pro is running the IP address assigned to the NIC's in those machines get changed from the initially assigned class C address to the default windows 169 series and of course the networking quits working on them as well. What I am trying to find out is if the smoothwall is acting as a local dhcp server, a local dns caching server as well as the gateway why is everything grinding to a halt whenever the ISP connection goes down? and what I can do to prevent it from stopping functions in the future. All machines have full local network addresses specified in hosts, host.sam files and the order of precedence is to resolve using those files first then dns. When ISP connection is down the linux boxes are all able to see the NFS shares by using the host file info but samba and windows boxes just go south for some reason. Any tips or help is appreciated.

3 4

MUUG Mailing Lists Migrated
by Trevor Cordes 18 Nov '16

18 Nov '16

The MUUG e-mailing lists (of which you are a subscriber if you are reading this email!) have been migrated from the old server to the new one. With this change we are encouraging everyone to update their address books (and spam exception lists, etc.) to use @muug.ca instead of the old @muug.mb.ca. For the time being, both domains will function, but from this point on, muug.ca will be the preferred domain. In the distant future, muug.mb.ca will probably go away. For example, to send email to the roundtable mailing list, you'd now send it to roundtable(a)muug.ca In addition, with the migration of the mailman mailing list web archives, thus concludes our migration of the entire MUUG web and ftp trove, and you can update your browser bookmarks to the new domain as well. If you notice any glitches, please let the MUUG board know. Thanks! Additional: I'd like to say a word of thanks to lisa, our venerable AMD dual-core muug server, having served us well for 5 years. Thanks lisa. And thanks to the U of M for having hosted us all those years! https://muug.ca/mona5.html (for the complete history) (For comparison, MUUG's 1994 server was a SPARCstation 2 with 1G disk and 16MB RAM!)

3 4

muug test 0
by Trevor Cordes 15 Nov '16

15 Nov '16

please ignore this test (we're working on the servers)

1 0

MUUG Meeting, Nov 8, 7:30pm -- Powerland Technology Announcement
by Gilbert E. Detillieux 01 Nov '16

01 Nov '16

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting on Tuesday, November 8. The meeting topic for this month is as follows: Powerland Technology Announcement The presentation this month will feature guest presenter Neil Thomson, from Powerland Computers. Neil is a senior solution architect at Powerland, and will be presenting some of the latest technology announced by HP and Intel. Daemon-Dash: nginx For this month's Daemon-Dash, Paul Sierks will present nginx, a high-performance web server using a modular event-driven architecture. AGM Plus, this month's meeting will be the MUUG annual general meeting, which includes the election of the MUUG board of directors for the 2016-2017 year (most likely by acclamation). The group holds its general meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. ****************************************************************** Please note our *NEW* meeting location for this month: *Room 1M28* (1st floor) Manitoba Hall, University of Winnipeg, entrance on Ellice Ave. between Spence St. and Balmoral St. Parking is available on the surrounding streets and in the lots on nearby streets. Look for signage once you're at the building, or ask a security guard. ****************************************************************** For more information about MUUG, and its monthly meetings, check out their web server: http://www.muug.mb.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board: http://www.muug.mb.ca/meetings/MUUGmeeting.pdf -- Manitoba UNIX User Group E-mail: <gedetil(a)muug.mb.ca> c/o Gilbert E. Detillieux Web: http://www.muug.mb.ca/ University of Manitoba Phone: (204)474-8161 Winnipeg MB CANADA R3T 2N2 Fax: (204)474-7609

1 0

Ubuntu Muug repo?
by Grigory Shamov 27 Oct '16

27 Oct '16

Hi All, Perhaps a strange question: I mostly use CentOS; and for it there is Muug repo, which is nice and fast and close. Now I am trying Ubuntu : is there a Muug Ubuntu repo, and if yes, what do I put into /etc/apt/sources.list to get it? -- Grigory Shamov Westgrid/ComputeCanada Site Lead University of Manitoba E2-588 EITC Building, (204) 474-9625

2 2

wacky NFS port problem
by Trevor Cordes 24 Oct '16

24 Oct '16

OK, this is a new one... Updated my kernel and rebooted tonight. Everything came up fine. Except dovecot (IMAP server). It complained: Error: service(imap-login): listen(*, 993) failed: Address already in use (993=imaps) OK. Except: #netstat -tulpn | grep 993 <nothing> #lsof -i:993 <nothing> #ss -t -l 'sport = 993' <nothing> A wasted hour later I did: netstat -n |grep 993 Sure enough I had a tcp connection between my workstation and my file server on 993 to 2049. grep 2049 /etc/services... eureka! 2049 is nfs. >From what I've figured out, nfs, which I have mount something on boot, randomly grabbed 993 before dovecot did, and was holding it as long as the nfs fs was mounted locally. And because nfs is in-kernel it didn't show up in lsof et al. I umounted it, waited for TIME_WAIT to expire and then I could start dovecot. *** This has never happened before on dozens of reboots... I guess it's pretty much luck / race condition what port nfs gets, especially with systemd possibly trying to do the mount and/or dovecot in parallel. I have no idea when it tries to do the mounts, but I'm guessing before dovecot. Note, I'm using NFSv4 which (unlike older NFS) uses TCP stateful in a persistent connection. Pretty much everything you know about v2/v3 throw away when it comes to using v4. I poked around nfs docs and google and found this option: resvport / noresvport Specifies whether the NFS client should use a privileged source port when communicating with an NFS server for this mount point. If this option is not specified, or the resvport option is specified, the NFS client uses a privileged source port. If the noresvport option is specified, the NFS client uses a non-privileged source port. This option is supported in kernels 2.6.28 and later. Refer to the SECURITY CONSIDERATIONS section for important details. OK, down there is a section: Using non-privileged source ports Which basically says using privileged ports is for security so normal users can't make/fake their own daemons and pretend to be any user they want. OK, so I know that's a bit hokey from a sec standpoint, but it's better than nothing, I guess. Regardless, having nfs client pick a random high port might hurt me also because I use some of them for my own purposes/daemons and I need them open also. The docs say this: "The exact range of privileged source ports that can be chosen is set by a pair of sysctls to avoid choosing a well-known port, such as the port used by ssh." Which would be perfect, except I can't find any further reference to these magic sysctls. I tried searching my box's /proc and /sys fs's for nfs & ports, nfs & priv, nfs & mount, etc. Couldn't find anything relevant. It would be really nice if I could specify the local source port, or at least specify the list of no-no ports using this elusive, promised, "sysctl". Anyone have any ideas? What a strange bug to run into. Chance of 1 in 1024 and it had to hit me.

2 4