related: https://forum.vyos.io/t/powerdns-recursor-returns-servfail-with-wan-load-balancer/3671/21
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Aug 20 2025
Aug 17 2025
Aug 15 2025
appears to be working again with VyOS 2025.08.13-0020-rolling
this might be interacting with firewall global-options receive-redirects
Aug 13 2025
many dns timeouts persist. is this interacting with wan load balancing?
Aug 1 2025
this issue persists, it's now manifesting itself in different ways. about 10% of DNS lookups from LAN clients still fail, now it's 10% of addresses looked up instead of 10% of queries total.
the ticket is closed, and
ssh vyos@vyos -- /opt/vyatta/bin/vyatta-op-cmd-wrapper show interfaces
Jul 31 2025
VyOS 2025.07.28-0022-rolling has completely broken the remote access connectivity.
set service dns forwarding cache-size 10000 set service dns forwarding system
appears to resolve the issue, any insights?
# python3 <<'EOF'
> import socket
> import time
> import struct
> import random
> import sys
>
> # --- Configuration ---
> DNS_SERVER = "8.8.8.8"
> DNS_PORT = 53
> QUERY_DOMAIN = "google.com"
> TIMEOUT = 1.0 # 1 second timeout
>
> # --- Counters ---
> success_count = 0
> timeout_count = 0
> total_count = 0
>
> def build_dns_query(domain_name):
> # Standard DNS query header
> transaction_id = random.randint(0, 65535)
> flags = 0x0100 # Standard query
> questions = 1
> header = struct.pack('!HHHHHH', transaction_id, flags, questions, 0, 0, 0)
>
> # Question section
> qname = b''
> for part in domain_name.split('.'):
> qname += struct.pack('B', len(part)) + part.encode('utf-8')
> qname += b'\x00' # End of QNAME
>
> qtype = 1 # A record
> qclass = 1 # IN class
> question = struct.pack('!HH', qtype, qclass)
>
> return header + qname + question
>
> def print_stats():
> global success_count, timeout_count, total_count
> if total_count == 0:
> return
>
> timeout_rate = (timeout_count / total_count) * 100
> status_line = (
> f"\rSuccess: {success_count} | "
> f"Timeouts: {timeout_count} | "
> f"Total: {total_count} | "
> f"Timeout Rate: {timeout_rate:.2f}% "
> )
> sys.stdout.write(status_line)
> sys.stdout.flush()
>
> print(f"--- Starting DNS timeout test against {DNS_SERVER} (Ctrl+C to stop) ---")
>
> try:
> while True:
> total_count += 1
> query = build_dns_query(QUERY_DOMAIN)
>
> sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
> sock.settimeout(TIMEOUT)
>
> try:
> sock.sendto(query, (DNS_SERVER, DNS_PORT))
> data, addr = sock.recvfrom(512)
> success_count += 1
> except socket.timeout:
> timeout_count += 1
> except Exception as e:
> # Handle other potential errors, though timeout is the one we expect
> timeout_count += 1
> finally:
> sock.close()
>
> print_stats()
> time.sleep(1)
>
> except KeyboardInterrupt:
> print("\n--- Test stopped. Final Statistics ---")
> print_stats()
> print("\n")
>
> EOF
--- Starting DNS timeout test against 8.8.8.8 (Ctrl+C to stop) ---
Success: 68 | Timeouts: 0 | Total: 68 | Timeout Rate: 0.00% ^C
--- Test stopped. Final Statistics ---
Success: 68 | Timeouts: 0 | Total: 68 | Timeout Rate: 0.00%Dec 4 2024
modifying any settings in the vpn block seems to break remote access until the vpn l2tp remote-access authentication local-users block is modified
still an issue in latest
Oct 31 2024
Sep 26 2024
What is the approach for preventing offloads from being added back in after boot? I deleting them before upgrading, upgraded to a nightly with this patch, but I observed the offloads returned:
Feb 18 2024
Feb 16 2024
interesting, it may have been broken sometime between 1.3.1 and 1.3.6 then. I used automations like these all the time. let me verify the behavior generally on ubuntu
Jan 29 2024
Feb 25 2023
Yes, apparently so from GitHub.