2degrees DNS - intermittent lookup failures

Forums › 2degrees (including Slingshot, Orcon, Flip, Stuff Fibre, MyRepublic, 2talk and Vocus) › 2degrees DNS - intermittent lookup failures

NickMack

962 posts

Ultimate Geek

Trusted

Lifetime subscriber

#318854 26-Feb-2025 20:30

Hi All,

Is anyone else seeing DNS lookup requests fail occasionally with 2degress? At home, I have Active Directory to manage my internal DNS that then looks up to Pi-hole (Version 6.x) forwarding via round robin to 2degrees DNS. (IPv4 - 111.69.69.68, 111.69.69.69,2406:e000:c07::1 or 2406:e000:c07::2)

Errors from today

2025-02-26 00:43:33.682 WARNING Connection error (2406:e000:c07::1#53): TCP connection failed (Operation in progress)
2025-02-26 00:43:43.921 WARNING Connection error (111.69.69.68#53): TCP connection failed (Operation in progress)
2025-02-26 00:43:49.041 WARNING Connection error (111.69.69.69#53): TCP connection failed (Operation in progress)
2025-02-26 08:43:48.274 WARNING Connection error (111.69.69.68#53): TCP connection failed (Operation in progress)
2025-02-26 08:43:58.514 WARNING Connection error (2406:e000:c07::1#53): TCP connection failed (Operation in progress)
2025-02-26 14:43:40.082 WARNING Connection error (2406:e000:c07::1#53): TCP connection failed (Operation in progress)
2025-02-26 14:43:50.323 WARNING Connection error (111.69.69.68#53): TCP connection failed (Operation in progress)

Nick

@Aspired

https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz

1 | 2

1571 posts

Uber Geek

#3348194 26-Feb-2025 20:54

I had problems with those servers a while ago (had them hard coded similar to yourself). Then checked what 2d was sending to me and now just use the following: 202.180.64.10 and 202.182.64.11.

NickMack

962 posts

Ultimate Geek

Trusted

Lifetime subscriber

#3348197 26-Feb-2025 20:59

nzkc:

I had problems with those servers a while ago (had them hard coded similar to yourself). Then checked what 2d was sending to me and now just use the following: 202.180.64.10 and 202.182.64.11.

I suspect that is due to you being on the Slingshot/Vocus network.

Nick.

https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz

nzkc

1571 posts

Uber Geek

#3348205 26-Feb-2025 21:17

NickMack:

nzkc:

I had problems with those servers a while ago (had them hard coded similar to yourself). Then checked what 2d was sending to me and now just use the following: 202.180.64.10 and 202.182.64.11.

I suspect that is due to you being on the Slingshot/Vocus network.

Nick.

Possibly. I _was_ with snap. And when I got migrated to 2d it wasnt completely painless (e.g. PPPoE stopped working). And I have since moved house so could have been moved then too

aspired

32 posts

Geek

ID Verified

Trusted

2degrees

#3348213 26-Feb-2025 22:28

Thanks @NickMack Think iv found the issue and hopefully resolved now, let me know how it goes.

NickMack

962 posts

Ultimate Geek

Trusted

Lifetime subscriber

#3348232 27-Feb-2025 06:42

aspired:

Thanks @NickMack Think iv found the issue and hopefully resolved now, let me know how it goes.

Thanks mate - no issues so far overnight ;-)

https://nick.mackechnie.co.nz | NZ ISP latency monitoring - https://smokeping.thenet.gen.nz

arjoll

22 posts

Geek

Subscriber

#3348714 28-Feb-2025 13:48

I spotted similar DNS issues in the traffic monitor on my Firebox T70 when I tried switching back to PPPoE from DHCP a couple of days ago to see if it resolved an issue with two of my Ring cameras which started at the same time as being switched from Snap to Slingshot last week. Issues with the Firebox getting DNS from 2d when doing PPPoE, saying it couldn't query those servers; here I have the home and IOT networks using DNS forwarding in the T70, while the work network points to the AD DCs.

I tried switching again this morning and didn't spot those DNS issues, only PPPoE authenticating then dropping.

(Turns out I can no longer connect via PPPoE, but that and the Ring problem that happened when I was switched are other issues entirely that I'm still working on!)

boosacnoodle

963 posts

Ultimate Geek

#3351512 8-Mar-2025 17:28

Yes. Works okay on v4.

traceroute to ns1.metaname.net (49.50.242.204), 30 hops max, 46 byte packets

1 * * *

2 default-rdns.vocus.co.nz (131.203.106.97) 18.457 ms 18.533 ms 19.238 ms

3 * * *

4 et-0-0-2-0.core02.qst.vygr.net (43.240.33.8) 18.870 ms 19.043 ms 18.824 ms

5 et-0-0-15-0.core02.pmd.vygr.net (43.240.33.59) 18.780 ms 18.784 ms 18.843 ms

6 et-0-0-3-0.edge01.pmd.vygr.net (43.240.33.127) 18.521 ms 18.584 ms 18.831 ms

7 113.21.224.21 (113.21.224.21) 18.605 ms 18.574 ms 18.480 ms

8 akl-2.metaname.net (49.50.242.204) 18.559 ms 18.449 ms 18.594 ms

But on v6, traffic destined for AKL is going ex. LON.

traceroute to ns1.metaname.net (2001:470:1f09:126e::1), 30 hops max, 72 byte packets

1 default-rdns.vocus.co.nz (2400:4800::2f) 2.207 ms 1.769 ms 1.599 ms

2 default-rdns.vocus.co.nz (2404:4408:1::112) 41.923 ms 40.252 ms 40.320 ms

3 * * *

4 e0-32.core1.per1.he.net (2001:470:0:203::2) 92.091 ms 92.368 ms 92.553 ms

5 * * *

6 * * *

7 * * *

8 * * *

9 port-channel8.core2.lon2.he.net (2001:470:0:626::1) 280.125 ms 279.253 ms 278.776 ms

10 tserv1.lon1.he.net (2001:470:0:67::2) 278.944 ms 277.656 ms 280.065 ms

11 akl-2.metaname.net (2001:470:1f09:126e::1) 541.621 ms 543.410 ms 541.453 ms

Regrettably, not a rare occurrence. 2degrees IPv6 just sucks.

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

yitz

2074 posts

Uber Geek

#3351514 8-Mar-2025 17:37

boosacnoodle:

But on v6, traffic destined for AKL is going ex. LON.

traceroute to ns1.metaname.net (2001:470:1f09:126e::1), 30 hops max, 72 byte packets

[..]

10 tserv1.lon1.he.net (2001:470:0:67::2) 278.944 ms 277.656 ms 280.065 ms

11 akl-2.metaname.net (2001:470:1f09:126e::1) 541.621 ms 543.410 ms 541.453 ms

Is that being tunneled ?? Looks like Metaname's set up rather than 2degrees.

boosacnoodle

963 posts

Ultimate Geek

#3351515 8-Mar-2025 17:39

Appears like there may just be straight up v6 congestion:

traceroute to 2001:470:1f09:126e::1 (2001:470:1f09:126e::1), 30 hops max, 80 byte packets

1 2404:4408:2:2908::e (2404:4408:2:2908::e) 0.456 ms 0.300 ms 0.501 ms

2 akl-2.metaname.net (2001:470:1f09:126e::1) 515.545 ms 515.495 ms 515.456 ms

boosacnoodle

963 posts

Ultimate Geek

#3351516 8-Mar-2025 17:40

yitz: Is that being tunneled ?? Looks like Metaname's set up rather than 2degrees.

That's from my router. From the 2d looking glass, we see that the hop is direct but with 500 ms latency.

yitz

2074 posts

Uber Geek

#3351517 8-Mar-2025 17:44

I think some 2degrees core routers do something weird with TTL propagation (either not implemented or blocked/disabled, a step further than many routers which rate limit ICMP) and as a result all intermediate hops beyond their core are missing on traceroutes it just goes straight to destination.

Reminds me of old Xtra D-Link DSL 302G modems that use to block traceroutes on Telecom shipped firmware.

You can just do a BGP query to find out whether it's a directly connected network.

noroad

949 posts

Ultimate Geek

Trusted

#3351638 9-Mar-2025 08:40

yitz:

I think some 2degrees core routers do something weird with TTL propagation (either not implemented or blocked/disabled, a step further than many routers which rate limit ICMP) and as a result all intermediate hops beyond their core are missing on traceroutes it just goes straight to destination.

What you are seeing in those traces is a consequence of IP transport over an MPLS network. The core transport over MPLS tunnels is not seen by the end user.

yitz

2074 posts

Uber Geek

#3351676 9-Mar-2025 13:09

noroad:

What you are seeing in those traces is a consequence of IP transport over an MPLS network. The core transport over MPLS tunnels is not seen by the end user.

This is affecting inter-domain hops though so possibly the ICMP TTLs not being rewritten at the other end of the MPLS tunnel due to filtering or some vendor interoperability issue? They block other stuff like dig traces too again only for traffic traversing those particular routers. It seems traffic to 2degrees peering partners are spared of this filtering. Feels very walled garden-ish compared to a "pure" internet connection.

Tinkerisk

4224 posts

Uber Geek

#3351711 9-Mar-2025 18:00

NickMack:

Hi All,

Is anyone else seeing DNS lookup requests fail occasionally with …XYZ? At home, I have Active Directory to manage my internal DNS that then looks up to Pi-hole (Version 6.x) forwarding via round robin to …

Nope. Because of a little extra step.

- NET: FTTH, OPNsense, 10G backbone, GWN APs, ipPBX
- SRV: 12 RU HA server cluster, 0.1 PB storage on premise
- IoT: thread, zigbee, tasmota, BidCoS, LoRa, WX suite, IR
- 3D: two 3D printers, 3D scanner, CNC router, laser cutter

boosacnoodle

963 posts

Ultimate Geek

#3351761 9-Mar-2025 19:53

No one is looking into this still?

PING6(56=40+8+8 bytes) xxx --> 2001:470:1f09:126e::1

16 bytes from 2001:470:1f09:126e::1, icmp_seq=0 hlim=48 time=608.923 ms

16 bytes from 2001:470:1f09:126e::1, icmp_seq=1 hlim=48 time=629.971 ms

16 bytes from 2001:470:1f09:126e::1, icmp_seq=2 hlim=48 time=546.223 ms

16 bytes from 2001:470:1f09:126e::1, icmp_seq=3 hlim=48 time=559.664 ms

16 bytes from 2001:470:1f09:126e::1, icmp_seq=4 hlim=48 time=578.053 ms

16 bytes from 2001:470:1f09:126e::1, icmp_seq=5 hlim=48 time=707.642 ms

16 bytes from 2001:470:1f09:126e::1, icmp_seq=6 hlim=48 time=725.043 ms

--- 2001:470:1f09:126e::1 ping6 statistics ---

8 packets transmitted, 7 packets received, 12.5% packet loss

round-trip min/avg/max/std-dev = 546.223/622.217/725.043/65.188 ms

1 | 2