New Feature: Support wide-area DNS-SD publishing about avahi HOT 9 OPEN

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.

from avahi.

Though you should know we have disabled wide-dns area support recently, because it contains unfixed issues.

from avahi.

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 NLnetLabs/ldns#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.

from avahi.

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.

from avahi.

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.

from avahi.

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 NLnetLabs/ldns#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.

from avahi.

@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.

from avahi.

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).

from avahi.

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 OpenPrinting/cups#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.

from avahi.