lathiat
New Feature: Support wide-area DNS-SD publishing
Currently only publishing via mDNS is supported. This would allow avahi to perform the client-side dance covered at http://www.dns-sd.org/ServerSetup.html and http://www.dns-sd.org/ClientSetup.html
#578 would presumably need to be fixed before this, though maybe calling out to nsupdate may be simpler and more maintainable (then avahi would not need to implement RFC 2136 and friends)?
We definitely do not want to reimplement classic authoritative DNS server to publish those records. Yes, dynamic updates are quite likely the best way to archieve that. Either by nsupdate command-line tool or by reusing some DNS library in better case. I would choose ldns for it. We need some decent fix to improve wide-area support in any case.
Though you should know we have disabled wide-dns area support recently, because it contains unfixed issues.
As mentioned elsewhere I don't think it makes sense to add new "wide-area" features at all.
I would choose ldns for it
I took a look at that library and to judge from https://github.com/NLnetLabs/ldns/blob/develop/.github/workflows/testsuite.yml it isn't even tested under ASan/UBSan on a regular basis (and currently its testsuite fails with a bunch on memory leaks under ASan as far as I can see). I haven't been able to find any fuzz targets there either. Looking at https://github.com/NLnetLabs/ldns/issues/166 I'm guessing it isn't fuzzed and relies on external bug reports. I'm sorry but I just don't think that it's suitable for handling DNS packets in its current form.
It is the best maintained dns specialized library I know. Alternative is also unbound library, but it is significantly heavier dependency. While I admit fuzzing is a great way to test a project, I don't think that is the most significant feature of a library. This is the best candidate I know. bind libraries were tested with fuzzers, but are not supported as library any more. I do not know alternative full-featured library. If you know better alternative, I am all ears. It is far better choice than custom in-house building of DNS packets, like we have so far.
Adding fuzzing testing to ldns would take significantly less efforts than fixing all potential issues in our custom code. I admit one of advantages (for me) is we already support it in RHEL and I am its co-maintainer on Fedora.
Alternative might be c-ares. I don't know how good it is inside, but is at least actively maintained and used. Has some github actions, which might satisfy you more. Has also some documentation, but I like ldns more. Could be useful alternative.
I were able to find tsig and update in ldns documentation. But my quick scan of c-ares docs did not find any support for dynamic updates, required for this feature.
It is the best maintained library dns specialized library
According to https://nlnetlabs.nl/projects/ldns/about/
In principle we only perform basic maintenance and bug fixes on ldns, and will only consider development of new functionality on ad-hoc basis
and given that for example https://github.com/NLnetLabs/ldns/pull/186 has been open since 2022 it seems to me that basic testing isn't included in the basic maintenance.
fuzzing it great thing to test projects, I don't think that is the most significant feature of a library
I kind of disagree. If C code that is supposed to parse network packets isn't fuzzed it can't be used in anything other than toy projects.
I do not know alternative full-featured library
I don't know either but I don't think it's necessary to bring a lot of new features in the first place.
@pemensik just to clarify I'd consider ldns if it got to the point where it takes much more than a second to discover out-of-bound writes like
=================================================================
==683215==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5310000247ff at pc 0x000000518a98 bp 0x7ffe812d43e0 sp 0x7ffe812d43d8
WRITE of size 1 at 0x5310000247ff thread T0
#0 0x518a97 in packetbuffromfile /home/vagrant/ldns/./drill/work.c:148:21
#1 0x518c85 in read_hex_pkt /home/vagrant/ldns/./drill/work.c:201:13
#2 0x510004 in main /home/vagrant/ldns/./drill/drill.c:809:10
#3 0x7f7c07565149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#4 0x7f7c0756520a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2820a) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#5 0x42dd34 in _start (/home/vagrant/ldns/drill/.libs/drill+0x42dd34) (BuildId: 348fa7522987d96528ada32341293ac284f1fb05)
0x5310000247ff is located 0 bytes after 65535-byte region [0x531000014800,0x5310000247ff)
allocated by thread T0 here:
#0 0x4cc232 in malloc (/home/vagrant/ldns/drill/.libs/drill+0x4cc232) (BuildId: 348fa7522987d96528ada32341293ac284f1fb05)
#1 0x51296d in xmalloc /home/vagrant/ldns/./drill/drill_util.c:284:6
#2 0x510004 in main /home/vagrant/ldns/./drill/drill.c:809:10
#3 0x7f7c07565149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#4 0x7f7c0756520a in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2820a) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#5 0x42dd34 in _start (/home/vagrant/ldns/drill/.libs/drill+0x42dd34) (BuildId: 348fa7522987d96528ada32341293ac284f1fb05)
SUMMARY: AddressSanitizer: heap-buffer-overflow /home/vagrant/ldns/./drill/work.c:148:21 in packetbuffromfile
Shadow bytes around the buggy address:
0x531000024500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x531000024580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x531000024600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x531000024680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x531000024700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x531000024780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[07]
0x531000024800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x531000024880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x531000024900: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x531000024980: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x531000024a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
in its codebase.
My feeling is shelling out to nsupdate keeps things simpler, as then all the auth stuff is up to the user to configure, avahi would only handle working out which records to create.
As for the use of wide-area DNS-SD, wide-area Airprint (a.k.a. finding CUPS printers outside of the current subnet) is a sufficiently useful test case (as it appears the only blocker is avahi not doing wide-area DNS-SD publishing).
the only blocker is avahi not doing wide-area DNS-SD publishing
The whole wide-area part needs revisiting and currently it's off by default. The ldns discussion is mostly related to how to resolve things properly and until it's fixed/redesigned new features are somewhat blocked.
finding CUPS printers outside of the current subnet
To judge from https://github.com/OpenPrinting/cups/issues/945
the current DNS-SD API provides access to everything needed to export the necessary information to a zone file or provide it to a server for incorporation into a DNS zone
so it should hopefully be possible to do all that outside of avahi in the meantime.
I'll go ahead and close it as no-planned.
The openthread project where border routers should support things like https://www.rfc-editor.org/rfc/rfc8766.html can probably be used instead.