In T2486#64335, @jjakob wrote:Also, this is reproducible with pdns-recursor from upstream master (4.4.0) so upgrading won't help.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
May 21 2020
May 21 2020
c-po moved T2456: netflow source-ip cannot be configured from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2471: PPPoE server: always add AdvAutonomousFlag when IPv6 is configured from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2470: Update to PowerDNS recursor 4.3 from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2469: Update Linux Kernel to v4.19.123 from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2480: NAT: after rewrite commit tells that dnat IP address is not locally connected from Need Triage to Finished on the VyOS 1.3 Equuleus board.
c-po moved T2481: WireGuard: support tunnel via IPv6 underlay from Need Triage to Finished on the VyOS 1.3 Equuleus board.
jjakob added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
c-po added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
Latest rolling runs PowerDNS recursor 4.3 T2470
jack9603301 added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
Although I wanted to try it out, it seems the best way is to try to upgrade to the latest stable version. From the perspective of version management, the higher version often fixes some existing bugs, while the stable version ensures sufficient testing to avoid 0days.
thomas-mangin added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
vyos@vyos:~$ dpkg -l | grep pdns ii pdns-recursor 4.2.1-1pdns.buster amd64 PowerDNS Recursor
jack9603301 added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
@jjakob I'm sorry, but I think you may have misunderstood me. I just summarized the problems that can be solved at present. Of course, this patch can finally be submitted to PDNS. Relatively speaking, the current solution to the problem may be the first priority, and there are only two main ways to solve the problem, either to solve it or to bypass it.
jjakob added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
In T2486#64339, @jack9603301 wrote:I can summarize the following solutions, and maybe there are other solutions:
a) Fix the bug yourself
b) Use other storage mechanisms to resolve records to bypass
c) Self parsing hosts
jjakob added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
If you mean we should maintain our own fork of powerdns, I'm against that. PowerDNS is open source and anyone can submit patches to it the same as VyOS. If you want to try fixing the bug in pdns-recursor, you can clone pdns, debug it, build it, test it and submit the patch at https://github.com/PowerDNS/pdns . Of course you have to oblige by their contribution guidelines that are listed there. They also have a IRC channel at OFTC #powerdns .
jack9603301 added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
I can summarize the following solutions, and maybe there are other solutions:
a) Fix the bug yourself
b) Use other storage mechanisms to resolve records to bypass
c) Self parsing hosts
jack9603301 added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
Alas, it's really a troublesome problem. If it's a bug, I haven't used pdns-recursor. I usually use ISC bind, but I have a solution different from the one you put forward. It is based on the independent maintenance of open source branches, looking for the code with problems and implementing the patch. @jjakob
jjakob added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
You mean that when pdns-recursor recursively forwards the request to the back-end recursive parsing service, the static entries in the query / etc / hosts will always return NXDOMAIN?
jack9603301 added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
You mean that when pdns-recursor forwards the query to the back-end recursive parsing service for the first time, after that, the static entries in query /etc/hosts will always return NODOMAIN.
jjakob added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
The full description and way to reproduce is at https://github.com/PowerDNS/pdns/issues/9136 since this is a pdns-recursor bug. But in essence, after pdns-recursor startup or restart, requests that come in to pdns-recursor (service dns forwarding in VyOS) for a domain from /etc/hosts work normally. Then a request for any other domain comes in, that gets forwarded via forward-zones-recurse (service dns forwarding name-server), for example google.com, that request gets resolved without errors, but causes this bug to manifest. After that, a request for any hostname from /etc/hosts returns NXDOMAIN.
jack9603301 added a comment to T2486: DNS records set via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone.
via 'system static-host-mapping' return NXDOMAIN from 'service dns forwarding' after a request to a forwarded zone
This is a 1300 byte ping running through a MACsec connection with wpa_supplicant for key management.
jjakob updated the task description for T2054: Changing "system name-server" doesn't update dns forwarding config, neither does "restart dns forwarding".
Unknown Object (User) closed T1876: IPSec VTI tunnels are deleted after rekey and dangling around as A/D as Resolved.
jjakob renamed T2463: DHCP-received nameserver not added to vyos-hostsd from DHCP-received nameserver not added to vyos-hostsd (with T2409 patch) to DHCP-received nameserver not added to vyos-hostsd.
Just to confirm, increasing the route,max_size fixed this issue completely. I think it can be closed. But maybe we should set these settings by default before closing this.
Unknown Object (User) closed T2364: Add CLI command for mroute , a subtask of T1729: PIM (Protocol Independent Multicast) implementation, as Resolved.
Unknown Object (User) closed T1820: VRRP transition scripts for sync-groups are not supported in VyOS (anymore) as Resolved.
Tested on 1.3-rolling-202005210117, works properly
I think the way to do this is in src/conf-mode/interfaces-ethernet.py in apply(), don't change the interfaces mac if eth['is_bond_member'] is set.
Unknown Object (User) created T2487: VRRP does not display info when group disabled.
May 20 2020
May 20 2020
jjakob added a parent task for T2465: DHCP isn't updating host file when hostfile-update enabled.: T2464: DNS bugs (parent task).
kroy changed the status of T2483: DHCP most likely not restarting pdns_recursor, a subtask of T2465: DHCP isn't updating host file when hostfile-update enabled., from In progress to Needs testing.
kroy changed the status of T2483: DHCP most likely not restarting pdns_recursor from In progress to Needs testing.
This PR419 should take care of this and the parent task
@richardpowellus you could test it on an 1.2.5 system by running the following commands:
related to T2088 where performance is also being discussed.
c-po closed T103: DHCP server prepends shared network name to hostnames, a subtask of T2464: DNS bugs (parent task), as Resolved.
c-po changed the status of T103: DHCP server prepends shared network name to hostnames, a subtask of T2464: DNS bugs (parent task), from Open to Needs testing.
c-po changed the status of T103: DHCP server prepends shared network name to hostnames from Open to Needs testing.
@krassle backported to crux branch
waiting for a decision on T2485 before doing this work
I have worked and provided a patch for T2485 .. It may be the right place to move it in.
Unknown Object (User) changed Version from VyOS 1.2.5epa1, VyOS 1.3 Rolling to VyOS 1.3 Rolling on T2477: Make VyOS interactively ask whether user trust remote host SSH fingerprint.
kroy changed the status of T2483: DHCP most likely not restarting pdns_recursor from Open to In progress.
No worries. I think I've got a simple fix for this. Just needed to step away for a bit
I think this should be fixed by the one that broke this, or no? I don't have the time to do any real work right now. Maybe in a week or 2.
Every call to /bin/cli-shell-api --show-working-only --show-show-defaults --show-ignore-edit showConfig takes multiples seconds (6?)
/usr/libexec/vyos/conf_mode/system-timezone.py call it twice.
/usr/libexec/vyos/conf_mode/nat.py call it twice
/usr/libexec/vyos/conf_mode/interfaces-loopback.py call it twice ... etc.
Not really, the change to nobody:nogroup was by c-po in https://github.com/vyos/vyos-1x/commit/f371946044696737d1649d9119665b96430d2328
The commit by me you referenced just fixed a bug that resulted from that change.
c-po added a comment to T2480: NAT: after rewrite commit tells that dnat IP address is not locally connected.
Fixed in https://github.com/vyos/vyos-1x/commit/bc06027 - task id missed in commit
This is related to this change:
For get_bridge_member_config, ifname_from_config and maceui64 to be able
to be moved into ifconfig.interfaces T2366 needs to be done first,
otherwise functionality will break.
Unknown Object (User) added a comment to T1999: support for ip groups in nat.
Note: When we migrate NAT to nftables, we need to use nftables sets instead of ipset
in full agreement
Definitely, I'm not saying NPT should be removed, just discouraged in favour of using routed public prefixes where available. If the user chooses tho use NPT, the option should definitely still be there.
In T421#64197, @jjakob wrote:That's a case where having the ability to assign addreses from the received prefix via DHCPv6 on the internal interface would allow internal hosts to get managed addresses from the prefix automatically without the use of NPT or SLAAC. But that isn't implemented yet AFAIK.
That's a case where having the ability to assign addreses from the received prefix via DHCPv6 on the internal interface would allow internal hosts to get managed addresses from the prefix automatically without the use of NPT or SLAAC. But that isn't implemented yet AFAIK.
Please see attached the full log of the boot process. I try to supply a PNG later on but I guess it will be really huge.
Even if dhcpv6-pd is now supported, nptv6 may still be needed, and as a user's choice, the application user may need to use the ula address. In particular, if you do not use ula addresses, in some environments, users may not be able to obtain fixed address prefixes, and when users need internal IPv6 address prefixes that can only be assigned by themselves, NPT may be necessary.Like myself.
I agree. NPTv6 was acceptable as a stopgap measure as VyOS didn't support DHCPv6-PD. Now that we have that (even though it's still young and needs testing), NPTv6 should be actively discouraged in the docs except for unavoidable cases, e.g. where the ISP wants to only give the client a single /64 but the client wants multiple L2 segments with IPv6, each needing its own /64 segment - unless there is a better alternative way to solve that I don't know of, other than demanding a /56 from the ISP or switching ISPs.
We definitely shouldn't be setting permissions on the socket to 777 or 666 - whoever has write access to it can modify the DNS configuration (pdns-recursor) and can thus inject malicious DNS records or add himself as a DNS forwarder and do MITM attacks.
Hehe... naming is difficult, I have that problem too :)
0-18 kernel boot
18-41 system starting inc FRR
70-120 the python most of the time is spend/wasted in cli-shell-api - so I would think reading the configuration file. If we can optimise / reduce this number of calls it would be very good.
140-220 is more or less firewall setup with vyatta-firewall / vyatta-upset.pl / ip6tables
kroy changed the status of T2465: DHCP isn't updating host file when hostfile-update enabled. from Open to Needs testing.
PR416 should be the real fix here and PR413 should be reverted.
May 19 2020
May 19 2020
thomas-mangin added a comment to T2474: Building instructions with Docker need a little more detail.
I need to double-check (and may not get to it) but if you use a vyos-build to build current and then try to build crux, make iso is not happy. I am now building crux using the command in my post above, the only difference: clean vyos-build install before the git checkout crux.
May 19 2020, 10:35 PM · Restricted Project
Yep. Confirmed, and that's the root issue here.
kroy changed the status of T2465: DHCP isn't updating host file when hostfile-update enabled. from Needs testing to Open.
jacobweinstock added a comment to T2465: DHCP isn't updating host file when hostfile-update enabled..
I tested the PR mentioned above and don't believe this will work. Reason is, is that https://github.com/vyos/vyos-1x/blob/current/src/systemd/isc-dhcp-server.service runs dhcpd as user: nobody and nobody is not in the sudo group, as far as i can tell. This is the error message im seeing.
bash May 19 21:37:45 vyos sudo[6141]: nobody : user NOT in sudoers ; TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/vyos-hostsd-client
May 19 2020, 9:32 PM · Restricted Project
21:39:35.057600 IP6 (flowlabel 0xba774, hlim 1, next-header UDP (17) payload length: 76) fe80::20d:b9ff:fe53:7ee.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=95b13f (client-ID hwaddr/time type 1 time 643212067 000db95307ec) (IA_NA IAID:1 T1:0 T2:0) (elapsed-time 1681) (option-request DNS-server DNS-search-list) (IA_PD IAID:2 T1:0 T2:0))