(m)DNS: improve (m)dnsd defaults and behavior

[gpotter2]

• fix various bugs in dnsd / mdnsd
• make it closer to real life (aa, ttl, id, opt)
• add missing mDNS specific bits

fixes https://github.com/secdev/scapy/issues/4388

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 71.69811% with 30 lines in your changes are missing coverage. Please review.

Project coverage is 81.56%. Comparing base (fa94fe3) to head (420665c). Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4390      +/-   ##
==========================================
- Coverage   82.20%   81.56%   -0.64%     
==========================================
  Files         352      352              
  Lines       83665    83953     +288     
==========================================
- Hits        68775    68476     -299     
- Misses      14890    15477     +587     

Files	Coverage Δ
scapy/arch/__init__.py	63.76% <66.66%> (-8.96%)	:arrow_down:
scapy/layers/dns.py	87.63% <71.84%> (-0.63%)	:arrow_down:

... and 26 files with indirect coverage changes

[gpotter2]

I've tweaked things quite a bit, trying to fix https://github.com/secdev/scapy/pull/4385#discussion_r1599926037. I've expanded the docstrings to add some usage examples.

The behavior on machines with multiple interfaces is very buggy.. that's because Scapy handles very poorly multicast link-layer addresses. This requires a rework but that's out of scope.

In the meantime, this code is usable on a machine with multiple interfaces using

conf.route.add(net="224.0.0.0/8", gw="<the gateway>", metric=1)

[evverx]

It seems I can still reproduce https://github.com/secdev/scapy/pull/4385#discussion_r1599926037 when mdnsd receives A and AAAA queries from avahi. It could be I screwed something up though so I'll try to double-check.

[gpotter2]

I'm personally able to have avahi-resolve work, but only on a non-loopback interface (with 2 machines). It seems to never be receiving any packet back. (maybe an issue of using lo on L2 with raw sockets?)

Check the source MAC though. I still need to ip route add 224.0.0.0/4 dev x.x.x.x metric 1. (this however is a Scapy issue..)

In all cases I'm really interested if you have feedback on this one :D

[evverx]

Turns out I screwed it up. I tested it with https://github.com/secdev/scapy/pull/4385. With this PR applied avahi-resolve -n works. Sorry!

[evverx]

I've just tested it with the loopback interface using

mdnsd(iface='lo', joker='192.168.56.100')

and it works too as far as I can see. allow-interfaces= and deny-interfaces= in avahi-daemon.conf should allow the loopback interface though.

[gpotter2]

When it's fine by you @evverx, I'll proceed with merging this :) I'm unsure if I've addressed all your comments / remarks.

[evverx]

I tested it with avahi, mDNSResponder and systemd-resolved and it works so personally I think it should be good to go :-)