From narellec at gmail.com Tue Aug 5 14:46:06 2025 From: narellec at gmail.com (Narelle Clark) Date: Tue, 5 Aug 2025 14:46:06 +1000 Subject: [AusNOG] Call for Papers APIX32 on 8 September Message-ID: Hi all After you've been to AusNOGthis year, why not go to APNIC and APIX? The APIX Program Committee now invites presentations for APIX32 scheduled for *Monday 8 September 2025* alongside APNIC60 *in Da Nang, Vietnam*. Suitable topics include:- - Internet Exchange ecosystem: topics related to the technical components of IXPs and their architectures - Internet Exchange operations: adopting new technology, monitoring and management of IXPs - Internet Exchange security: threats, mitigations and use cases in the IXP context - Internet Exchange growth and organisation: attracting new members, onboarding them and keeping them involved - Assessment and analysis of the impact of Internet Exchanges on the Internet ecosystem - Internet landscape generally: what big picture issues affect IXPs or their members - Data centre ecosystem: what trends are we seeing, what features and technology makes a DC a good home for an IXP? - Any other topics related to Internet and IXP operations. Presentations need to be of a practical orientation and directly assist the IXP community in establishing, running and growing IXPs. The intention is knowledge sharing and skill enhancement. Presentations aimed just at trying to sell services will not be accepted. Presentations can be given in person or remotely. There will also be a new member session where we are introduced to new IXPs in the region and we welcome any recommendations people have for interesting sessions and speakers! Papers can be submitted via the APIX 32 Submission System Or directly via this link: https://papers.apnic.net/user/index.php?event=228 *Submission deadline: 22 August 2025 Conference date : 8 September 2025* Thank you -- Narelle Clark Chair, APIX Program Committee and CEO Internet Association of Australia Proud operators of IX Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From glp71s at gmail.com Thu Aug 7 12:46:18 2025 From: glp71s at gmail.com (Giles Pollock) Date: Thu, 7 Aug 2025 12:46:18 +1000 Subject: [AusNOG] Anyone tried using the NBNCo status/outages customer facing page lately? In-Reply-To: References: Message-ID: So I've been checking the page for about a week now and it would seem someone has broken it with a bad implementation of reCAPTCHA. Naturally of course there is no way to actually reach anyone in NBNCo to look at getting the thing fixed, so this email is a bit of a scream to the void in the hope there might be someone out there who can raise something internally, or at least find the relevant webdev to prod... The steps to reproduce are pretty easy... Head on over to the status page ( https://www.nbnco.com.au/support/network-status), type in an address, click Check Address and watch it not work. Sometimes it will say you don't have NBN at that address, other times it will say there was an error and to try again later. Checking the actual requests will show a 500 error when trying to hit https://places.nbnco.net.au/places/v1/maintenance?locationId=(whatever your LOC ID is) with the response of "Invalid recaptcha response." You'd think there might be some testing somewhere before publishing a critical customer facing page... Have things continued to deteriorate when it comes to getting NBNCo issues sorted out? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at kobayashi.au Thu Aug 7 13:40:05 2025 From: matthew at kobayashi.au (Matthew Kobayashi) Date: Thu, 7 Aug 2025 13:40:05 +1000 Subject: [AusNOG] Anyone tried using the NBNCo status/outages customer facing page lately? In-Reply-To: References: Message-ID: Hi Giles, The reCAPTCHA implementation does work, it just requires the reCAPTCHA token to be passed as a header in the request. I'm not seeing any issues with the website either, maybe it's an issue with your browser? Try clearing cache, etc. and see if that sorts it out. Cheers, Matthew On Thu, 7 Aug 2025 at 12:47, Giles Pollock wrote: > So I've been checking the page for about a week now and it would seem > someone has broken it with a bad implementation of reCAPTCHA. Naturally of > course there is no way to actually reach anyone in NBNCo to look at getting > the thing fixed, so this email is a bit of a scream to the void in the hope > there might be someone out there who can raise something internally, or at > least find the relevant webdev to prod... > > The steps to reproduce are pretty easy... Head on over to the status page ( > https://www.nbnco.com.au/support/network-status), type in an address, > click Check Address and watch it not work. Sometimes it will say you don't > have NBN at that address, other times it will say there was an error and to > try again later. > > Checking the actual requests will show a 500 error when trying to hit > https://places.nbnco.net.au/places/v1/maintenance?locationId=(whatever > your LOC ID is) with the response of "Invalid recaptcha response." > > You'd think there might be some testing somewhere before publishing a > critical customer facing page... Have things continued to deteriorate when > it comes to getting NBNCo issues sorted out? > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glp71s at gmail.com Thu Aug 7 13:53:06 2025 From: glp71s at gmail.com (Giles Pollock) Date: Thu, 7 Aug 2025 13:53:06 +1000 Subject: [AusNOG] Anyone tried using the NBNCo status/outages customer facing page lately? In-Reply-To: References: Message-ID: Already cleared the cache, I suspect it might be a CDN issue at this stage as the recaptcha token isn't getting attached to the request for the maintenance API endpoint. It is being attached to the details endpoint though. I've tried a number of different devices (mobile and desktop) as well, so my next step is to force a VPN to somewhere weird and see if I get a different bunch of javascript sent my way. On Thu, Aug 7, 2025 at 1:40?PM Matthew Kobayashi wrote: > Hi Giles, > > The reCAPTCHA implementation does work, it just requires the reCAPTCHA > token to be passed as a header in the request. I'm not seeing any issues > with the website either, maybe it's an issue with your browser? Try > clearing cache, etc. and see if that sorts it out. > > Cheers, > Matthew > > On Thu, 7 Aug 2025 at 12:47, Giles Pollock wrote: > >> So I've been checking the page for about a week now and it would seem >> someone has broken it with a bad implementation of reCAPTCHA. Naturally of >> course there is no way to actually reach anyone in NBNCo to look at getting >> the thing fixed, so this email is a bit of a scream to the void in the hope >> there might be someone out there who can raise something internally, or at >> least find the relevant webdev to prod... >> >> The steps to reproduce are pretty easy... Head on over to the status page >> (https://www.nbnco.com.au/support/network-status), type in an address, >> click Check Address and watch it not work. Sometimes it will say you don't >> have NBN at that address, other times it will say there was an error and to >> try again later. >> >> Checking the actual requests will show a 500 error when trying to hit >> https://places.nbnco.net.au/places/v1/maintenance?locationId=(whatever >> your LOC ID is) with the response of "Invalid recaptcha response." >> >> You'd think there might be some testing somewhere before publishing a >> critical customer facing page... Have things continued to deteriorate when >> it comes to getting NBNCo issues sorted out? >> _______________________________________________ >> AusNOG mailing list >> AusNOG at lists.ausnog.net >> https://lists.ausnog.net/mailman/listinfo/ausnog >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitchkelly24 at gmail.com Sat Aug 9 01:30:55 2025 From: mitchkelly24 at gmail.com (Mitch Kelly) Date: Fri, 8 Aug 2025 23:30:55 +0800 Subject: [AusNOG] SAS Cables in Perth Message-ID: Good Evening Noggers. I'm in need of 3x SAS-8087 to SFF-8087 Cables for a Backplane that has an unscheduled disassembly, Perth area :) If you can be of assistance please reach out. [image: image.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 121514 bytes Desc: not available URL: From spoofer-info at caida.org Sat Aug 9 03:00:32 2025 From: spoofer-info at caida.org (CAIDA Spoofer Project) Date: Fri, 8 Aug 2025 10:00:32 -0700 Subject: [AusNOG] Spoofer Report for AusNOG for Jul 2025 Message-ID: <1754672432.342618.21250.nullmailer@caida.org> In response to feedback from operational security communities, CAIDA's source address validation measurement project (https://spoofer.caida.org) is automatically generating monthly reports of ASes originating prefixes in BGP for systems from which we received packets with a spoofed source address. We are publishing these reports to network and security operations lists in order to ensure this information reaches operational contacts in these ASes. This report summarises tests conducted within aus. Inferred improvements during Jul 2025: none inferred Source Address Validation issues inferred during Jul 2025: ASN Name First-Spoofed Last-Spoofed 152107 2024-02-25 2025-07-31 150369 2025-01-30 2025-07-06 Further information for these tests where we received spoofed packets is available at: https://spoofer.caida.org/recent_tests.php?country_include=aus&no_block=1 Please send any feedback or suggestions to spoofer-info at caida.org From jocelyn at ausnog.net Sat Aug 9 08:37:35 2025 From: jocelyn at ausnog.net (AusNOG) Date: Sat, 9 Aug 2025 08:37:35 +1000 Subject: [AusNOG] Lightning Talks @AusNOG Message-ID: <99C90217-1DDB-41BD-8325-7093C1325D8C@ausnog.net> An HTML attachment was scrubbed... URL: From david at hughes.id Wed Aug 13 16:54:09 2025 From: david at hughes.id (david at hughes.id) Date: Wed, 13 Aug 2025 16:54:09 +1000 Subject: [AusNOG] AusNOG 2025 has Sold Out Message-ID: <16FB0F5F-D3DA-45E1-9C1C-1DE87A49378E@hughes.id> Afternoon everyone Just a quick note to advise that all tickets for AusNOG 2025 have now been sold. Thank you to everyone that purchased a ticket. We're super excited and look forward to seeing all 500 of you in Melbourne in a few weeks. Regards, David on behalf of the AusNOG Team From marka at isc.org Thu Aug 14 12:26:22 2025 From: marka at isc.org (Mark Andrews) Date: Thu, 14 Aug 2025 12:26:22 +1000 Subject: [AusNOG] How you can help prevent DNS spoofing attempts from succeeding Message-ID: <54C51D37-4B38-43C4-8FFE-4F162E5B93D2@isc.org> Back in May 2016, RFC 7873 - Domain Name System (DNS) Cookies was published. This provides a mechanism that can make off path spoofing attacks impossible without all the management required by DNSSEC. This however only works if DNS servers and DNS clients implement the changes required. For a DNS server operator there are no real risks in enabling DNS COOKIE support other than ensuring all the servers in an anycast cluster have DNS COOKIES enabled. For DNS clients there is a small risk that you will make a request to a DNS server that has a broken DNS implementation that breaks DNS resolution. That said the number of such servers have been dropping over the last 9 years and per server workarounds are rare. I would like to encourage everyone on this list to check if their DNS servers have DNS COOKIE enabled or not and if it is not enabled to enable it or upgrade the server to one which supports it. You can test whether your server supports DNS COOKIE or not using https://ednscomp.isc.org/ednscomp At a minimum please test to see if you have a broken DNS server and correct it if your do. Below is the results of testing the .AU servers. Here A.AU supports DNS COOKIES as can be see by this field in the response "docookie=ok,cookie+badcookie?. ?badcookie? indicates that it is also configured to use DNS COOKIE to identify legitimate traffic when amplification attacks happen. The other servers cleanly accept requests with DNS COOKIES present but do not return DNS COOKIES so they are not providing anti-spoofing support for the clients that use those servers. The "docookie=timeout" are false negatives base on manual testing, the test is presumably hitting a rate limit. EDNS Compliance TesterChecking: 'au' as at 2025-08-14T01:59:15Z au. @65.22.199.1 (t.au.): dns=ok zflag=ok edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok,nsid,expire,subnet (LAX3) au. @2a01:8840:c1::1 (t.au.): dns=ok zflag=ok edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok,nsid,expire,subnet (YYZ3) au. @58.65.254.1 (a.au.): dns=ok zflag=ok edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok,cookie+badcookie edns512tcp=ok optlist=ok,nsid,cookie+badcookie,subnet (lax2) au. @2407:6e00:254::1 (a.au.): dns=ok zflag=ok edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok,cookie+badcookie edns512tcp=ok optlist=ok,nsid,expire,cookie+badcookie (mel3) au. @65.22.196.1 (q.au.): dns=ok zflag=timeout edns=timeout edns1=ok edns at 512=ok ednsopt=timeout edns1opt=ok do=timeout ednsflags=ok docookie=ok edns512tcp=ok optlist=timeout au. @2a01:8840:be::1 (q.au.): dns=ok zflag=timeout edns=timeout edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=timeout ednsflags=ok docookie=timeout edns512tcp=ok optlist=timeout au. @65.22.197.1 (r.au.): dns=ok zflag=ok edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok,nsid,expire,subnet (app4.mia2.hosts.meta.redstone.afilias-nst.info-1615580861) au. @2a01:8840:bf::1 (r.au.): dns=ok zflag=ok edns=ok edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=ok optlist=ok,nsid,expire,subnet (syd3.micro.hosts.meta.redstone.afilias-nst.info-1626964915) au. @65.22.198.1 (s.au.): dns=ok zflag=ok edns=timeout edns1=ok edns at 512=ok ednsopt=ok edns1opt=ok do=timeout ednsflags=ok docookie=timeout edns512tcp=ok optlist=ok,nsid,expire,subnet (sjc1.micro.hosts.meta.redstone.afilias-nst.info-1633459055) au. @2a01:8840:c0::1 (s.au.): dns=ok zflag=ok edns=timeout edns1=ok edns at 512=ok ednsopt=timeout edns1opt=ok do=timeout ednsflags=ok docookie=ok edns512tcp=ok optlist=ok,nsid,expire,subnet (sjc1.micro.hosts.meta.redstone.afilias-nst.info-1633459055) Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gogroup.au at gmail.com Thu Aug 14 20:53:34 2025 From: gogroup.au at gmail.com (Go Group - Go Pages - Go Ogle - Go Live 12/12/25) Date: Thu, 14 Aug 2025 20:23:34 +0930 Subject: [AusNOG] How you can help prevent DNS spoofing attempts from succeeding In-Reply-To: <54C51D37-4B38-43C4-8FFE-4F162E5B93D2@isc.org> References: <54C51D37-4B38-43C4-8FFE-4F162E5B93D2@isc.org> Message-ID: G'Day Mark I have been working with LANs/WANs since the early 90's. I started with banyan vines & LANtastic , NETware & more recently IP sockets programming & I feel this is too complicated for me being big into KISS - sorry to be so blunt :) KISS for me is I made a change to my email addresses 25+ years ago & started using sub-domains when I notice that spammers only tried to guess the left of the "@' ( Mailbox name ) & never the sub-domains & due to this have not had a spam msg. to any of my self hosted domains in ~20 years, but I get spam to the gmail accounts, for me this is KISS in action :( On my current project Ogle the world's 1st GEO Results Engin. we made some really bad assumptions. - We thought the DNS root servers would have domains that are prefixed with numbers 1st eg.http://byronbay.2o.au/ ( NSW Go Pages ) but numbers are after letters in DNS root server collating sequence. - We thought the US bug ( ! big ) tech would leave us alone when they realised we had designed a system only for Australians & were are not going to charge to use our AI to generate the Go Pages - We thought we could stand up our chrome extension, DNS server app that allow Australia's users to have a list of .au domains & the server would return a list IPs & not even attempt to resolve, so much faster >From my experience as a team member managing the most popular web site in southern hemisphere I believe we need to start thinking about having a "elevated" .au domain res. system I think Australia needs ITs own root servers & a method to allow for 'No need to resolve' domain list because nothing I have seen so far when IT comes to "DNS Security" is anything but an oxymoron. Australia is easily the richest country in the world we are about to give the .us half a trillion dollars hoping we get AUKUS Subs, we give billions of dollars in GAS to .jp who sell IT for a profit, we subsidise GAS to .cn, every Australian has a superannuation account & hackers outside Australia are incredibly motivated to steal this cash, our banks ( I have worked for 2 of them ) regularly let OS criminals open bank accounts & Westpac was convicted of 23 million breaches of anti-money laundering & paid a 1.3 billion penalty. I think this is only going to get worse :( Any1 interested in a Australian only WAN Ken G. Go G. BTW - I'm under no illusion this is not going to be easy, especially when you think about TOR exits etc. etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholas.scaglione at uconn.edu Fri Aug 15 06:11:43 2025 From: nicholas.scaglione at uconn.edu (Scaglione, Nicholas) Date: Thu, 14 Aug 2025 20:11:43 +0000 Subject: [AusNOG] Source Address Validation (SAV) Deployment and Operational Practices Message-ID: Friends: uRPF and similar SAV techniques have been around for long, with new variants recently/being standardized by the IETF (EFP-uRPF, BAR-SAV). We have done simulations to evaluate the impacts of these variants. To improve our research, we set up a short, quick survey for network managers and administrators of ASNs. In this study, we want to understand the deployment challenges, operational considerations, adoption trends and operator concerns in this area. It would be amazing if you could respond to the survey, available in: https://forms.gle/3rRtCTa2xk217tyd6 We really appreciate your help. The form also contains an option to leave your email for us to send you our research results (paper, simulations, survey). Thanks a lot!! ----------------------------------- Nicholas Scaglione Ph.D. Student School of Computing [UConn Wordmark] -------------- next part -------------- An HTML attachment was scrubbed... URL: From marka at isc.org Fri Aug 15 06:51:43 2025 From: marka at isc.org (Mark Andrews) Date: Fri, 15 Aug 2025 06:51:43 +1000 Subject: [AusNOG] Protection from spoofing of DNS responses and TCP Message-ID: <20E0C2CF-2804-4529-A1C5-5464FD0F333F@isc.org> Yesterday I was talking about DNS COOKIE and protecting from spoofing. Now if the server you are talking to doesn?t support DNS COOKIE the client can always retry over TCP. Well I experimented with this and found that it works with some extra latency with the exception of 1-2% of queries that just failed because server didn?t support TCP as a fallback as is required by RFC 7766 - DNS Transport over TCP - Implementation Requirements. In named I added ?server 0.0.0.0/0 { require-cookie yes; };? and "server ::/0 { require-cookie yes; };? to named.conf which turns on this behaviour for all IPv4 and IPv6 servers unless there is a more specific server clause so you can try this yourself if you want. TCP is an interoperability requirement for DNS. There are nameservers out there that attempt to detect spoofed replies and switch to TCP mode. DNS has ALWAYS fallen back to TCP when answers are too big to fit in the UDP DNS message. We get from time to time reports of DNS lookups failing because DNS over TCP is being blocked and all we can say is contact the server operator and get them to fix their configuration. Please check, from outside your network, that your DNS servers are reachable over TCP. I?d like to be able to change named?s defaults to the equivalent of adding those two server clauses but the there are too many misconfigured servers out there. The latency will get better as more servers support DNS COOKIE (which requires the server to support TCP by the way.) What won?t get better without help is fixing the misconfigurations which block the TCP fallback. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From xrobau at gmail.com Sat Aug 16 22:00:59 2025 From: xrobau at gmail.com (Rob Thomas) Date: Sat, 16 Aug 2025 22:00:59 +1000 Subject: [AusNOG] Should I set up 'AusNOG plays Pokemon'? Message-ID: I suspect that most of us are aware of the 'Twitch Plays Pokemon' concept. I have run a couple of $xxx plays Pokemon over VoIP. Is this old and busted? Or should I set it up for AusNOG +613? If so: Which pokemon? I think Red, because PokeRed has ALWAYS been my Favourite, but I'm always happy to be yelled at. Feel free to @ me on B4P if you're there, or email me directly. Please do not spam the AusNOG ML with Pokemon stuff. If you click 'reply all', you're the Magikarp --Rob From marka at isc.org Mon Aug 18 11:35:49 2025 From: marka at isc.org (Mark Andrews) Date: Mon, 18 Aug 2025 11:35:49 +1000 Subject: [AusNOG] IPv6 and DNS Message-ID: <54BB6CAE-48C2-4FA7-8C18-16D06F8382E7@isc.org> The IETF is currently updating the requirements for IPv6 support with respect to the DNS (https://datatracker.ietf.org/doc/draft-ietf-dnsop-3901bis/04/). Basically the new requirements are that every zone is required to have both an IPv4 and and IPv6 servers to be compliant. RFC 3901 only required IPv4 servers. It all points out some common configuration errors that happen when trying to do this like missing glue, delegation NS records only being in one family, etc. I happened to be looking at the nameservers for optusnet.com.au because they where not accepting TCP queries as is required by RFC 7766 and noticed that this zone provides a perfect example of the things that can go wrong if you don?t take care. The zone has nameservers that support both IPv4 and IPv6 but the delegating nameservers only support IPv4. The Akamai servers are all dual stacked. This could fixed by adding the Akamai servers to the delegation. This would also remove the single point of failure at the DNS level where all the servers are behind the same AS. The Akamai servers also accept TCP connections so the zone would be resolvable if the clients needs to protect itself from spoofing attacks as ns1.optusnet.com.au and ns2.optusnet.com.au don?t have DNS COOKIE enabled. This was not to pick on Optus. I?m sure I could find other .AU zones that are equally poorly managed. Mark % dig ns optusnet.com.au @a.au ;; BADCOOKIE, retrying. ; <<>> DiG 9.21.3-dev <<>> ns optusnet.com.au @a.au ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12659 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: e366cdde819deb8b0100000068a280b6444cb1752c17d62a (good) ;; QUESTION SECTION: ;optusnet.com.au. IN NS ;; AUTHORITY SECTION: optusnet.com.au. 3600 IN NS ns1.optusnet.com.au. optusnet.com.au. 3600 IN NS ns2.optusnet.com.au. ;; ADDITIONAL SECTION: ns2.optusnet.com.au. 3600 IN A 203.2.75.12 ns1.optusnet.com.au. 3600 IN A 203.2.75.2 ;; Query time: 33 msec ;; SERVER: 58.65.254.1#53(a.au) (UDP) ;; WHEN: Mon Aug 18 11:24:06 AEST 2025 ;; MSG SIZE rcvd: 140 % dig ns optusnet.com.au @203.2.75.2 ; <<>> DiG 9.21.3-dev <<>> ns optusnet.com.au @203.2.75.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62297 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;optusnet.com.au. IN NS ;; ANSWER SECTION: optusnet.com.au. 86400 IN NS a9-67.akam.net. optusnet.com.au. 86400 IN NS ns1.optusnet.com.au. optusnet.com.au. 86400 IN NS ns2.optusnet.com.au. optusnet.com.au. 86400 IN NS a1-70.akam.net. optusnet.com.au. 86400 IN NS a11-65.akam.net. optusnet.com.au. 86400 IN NS a2-65.akam.net. optusnet.com.au. 86400 IN NS a24-66.akam.net. optusnet.com.au. 86400 IN NS a26-66.akam.net. ;; Query time: 24 msec ;; SERVER: 203.2.75.2#53(203.2.75.2) (UDP) ;; WHEN: Mon Aug 18 11:26:26 AEST 2025 ;; MSG SIZE rcvd: 211 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From phil.mawson at gmail.com Mon Aug 18 16:25:28 2025 From: phil.mawson at gmail.com (Phil Mawson) Date: Mon, 18 Aug 2025 16:25:28 +1000 Subject: [AusNOG] Lightning Talks @AusNOG In-Reply-To: <99C90217-1DDB-41BD-8325-7093C1325D8C@ausnog.net> References: <99C90217-1DDB-41BD-8325-7093C1325D8C@ausnog.net> Message-ID: Hi All, Please note we are extending lightning talk submissions until Monday 1st September to allow more time. Also note the contact address below is incorrect, please submit via our CFP system - https://cfp.ausnog.net/ Thanks and see you all in 2 weeks at AusNOG in Melbourne. Cheers, Phil On behalf of the AusNOG Program Committee. > On 9 Aug 2025, at 8:37?am, AusNOG wrote: > > > AusNOG 2025 is just around the corner and there are a couple of spots available for Lightning Talks. > > Have you been working on something interesting you want to share? > > Lightning Talks are 5 minutes or less so it's a great introduction to speaking at AusNOG. > > If you'd like to submit a Lightning Talk proposal, please send through the details to program at lists.ausnog.com before Monday 18th August. > > Talks must be technical, or relevant to the industry, and not include company promotion. > > See you in Melbourne! > > Kind Regards, > > Jocelyn Bateman > Program Chair > AusNOG > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.heinrich at cmlh.id.au Tue Aug 19 15:02:22 2025 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Tue, 19 Aug 2025 15:02:22 +1000 Subject: [AusNOG] iiNet Breach Message-ID: https://help.iinet.net.au/information-on-cyber-incident https://www.iinet.net.au/sites/iinet/files/2025-08/Media-statement_iiNet-cyber-incident.pdf -- Regards, Christian Heinrich http://cmlh.id.au/contact From Steven.Waite at comtel.com.au Tue Aug 19 17:44:00 2025 From: Steven.Waite at comtel.com.au (Steven Waite) Date: Tue, 19 Aug 2025 07:44:00 +0000 Subject: [AusNOG] Optus Message-ID: <3d7c1f9cfd3748f3819edf132fd126cf@comtel.com.au> Good Afternoon Can someone please contact from Optus would seem I have a routing issue to 8.8.8.8 Thanks Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From hudrob at gmail.com Tue Aug 19 22:06:34 2025 From: hudrob at gmail.com (Robert Hudson) Date: Tue, 19 Aug 2025 22:06:34 +1000 Subject: [AusNOG] iiNet Breach In-Reply-To: References: Message-ID: Sawn a phishing email today trying to collect payment data to The Messaging Company from an @internode.on.net email address. Coincidence? I don't believe in them... On Tue, 19 Aug 2025 at 15:02, Christian Heinrich < christian.heinrich at cmlh.id.au> wrote: > https://help.iinet.net.au/information-on-cyber-incident > > https://www.iinet.net.au/sites/iinet/files/2025-08/Media-statement_iiNet-cyber-incident.pdf > > > -- > Regards, > Christian Heinrich > > http://cmlh.id.au/contact > _______________________________________________ > AusNOG mailing list > AusNOG at lists.ausnog.net > https://lists.ausnog.net/mailman/listinfo/ausnog > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.welker at nemostar.com.au Tue Aug 26 14:55:17 2025 From: stephen.welker at nemostar.com.au (Stephen Welker) Date: 26 Aug 2025 14:55:17 +1000 Subject: [AusNOG] IPv6 and DNS In-Reply-To: <54BB6CAE-48C2-4FA7-8C18-16D06F8382E7@isc.org> References: <54BB6CAE-48C2-4FA7-8C18-16D06F8382E7@isc.org> Message-ID: <3db769e2-c6fe-4796-afc0-3c9241c496f3@nemostar.com.au> Exploring from an email deliverability perspective, using online.telstra.com.au as an example - important for billing purposes. On 18/8/2025 11:35, Mark Andrews wrote: > The IETF is currently updating the requirements for IPv6 support with respect > to the DNS (https://datatracker.ietf.org/doc/draft-ietf-dnsop-3901bis/04/). > > Basically the new requirements are that every zone is required to have both > an IPv4 and and IPv6 servers to be compliant. RFC 3901 only required IPv4 > servers. It all points out some common configuration errors that happen > when trying to do this like missing glue, delegation NS records only being > in one family, etc. > > I happened to be looking at the nameservers for optusnet.com.au because they > where not accepting TCP queries as is required by RFC 7766 and noticed that > this zone provides a perfect example of the things that can go wrong if you > don?t take care. The zone has nameservers that support both IPv4 and IPv6 but > the delegating nameservers only support IPv4. The Akamai servers are all dual > stacked. This could fixed by adding the Akamai servers to the delegation. > This would also remove the single point of failure at the DNS level where all > the servers are behind the same AS. The Akamai servers also accept TCP connections > so the zone would be resolvable if the clients needs to protect itself from > spoofing attacks as ns1.optusnet.com.au and ns2.optusnet.com.au don?t have DNS > COOKIE enabled. > > This was not to pick on Optus. I?m sure I could find other .AU zones that are > equally poorly managed. When receiving email our mail servers check for a valid return path (MAIL FROM) - the sending servers must have MX and IP address (at least for bounce messages). For online.telstra.com.au (hosted via/at outlook.com) they have IPv4 stack implemented fully, IPv6 is not fully implemented, thus when email is received via IPv6 it is rejected for not having IPv6 IPs. If you are experiencing poor email delivery have a look at IPv6 delegation, MX, and IPv6 settings. -- regards, Stephen Welker.