Beiträge von Chris M.

    Nur mal so aus fachlicher Sicht, du weißt was du da planst?


    Ich betreibe zwar bei mir intern einen redundanten PowerDNS Auth, PowerDNS Rec, dnsdist, PDNS-Admin Stack, aber ich weiß auch das das Zeug niemals die Welt sehen sollte. Nicht weil es nicht toll funktioniert sondern, weil DNS einfach so unglaublich komplex ist, und ich jetzt mal mutmaße das du genauso wenig Operational Knowledge im public Betrieb zu sowas hast wie ich. Ausser du beabsichtigst das nur Intern zu verwenden, dann kannst du das eigentlich auch auf bestehende Server einfach drauf werfen und gut ist. PowerDNS Auth reicht für sowas z.B. vollkommen aus und braucht keine Ressourcen da ist sogar dein piko Server schon absolut overkill.


    Mein Stack ist ein alpine linux virt mit docker compose und braucht ohne den PDNS-Admin vielleicht <256Mb Arbeitsspeicher.


    So wie ich es verstehe möchte sich Nighlander seine eigenen public (hoffentlich "nur" authoritative) DNS aufsetzen.

    Was man natürlich beachten sollte ist, dass man relativ schnell bei einer amplification attack dabei sein kann oder selbst Ziel (blackholed wird und damit keine neuen Freunde gefunden hat).

    Für zumindest bind gibt es ein meiner Meinung nach gutes best practice sheet als Anfang https://kb.isc.org/docs/bind-best-practices-authoritative

    (Natürlich sollte man sich vorher mit DNS beschäftigen, weiß aber keiner ob nicht doch Erfahrung da ist :))

    "Domain not found" deutet auf DNS Problem des outbound-Mailservers mit der empfangenden Domain hin (wo auch immer die liegen)


    Das ein Anbieter oder jemand die eigenen outbound-Mailserver auf dane only konfiguriert wäre dann doch etwas "masochistisch" ^^ :D

    Hier ist auch einer, Standard RS1000:


    []# curl -sL yabs.sh | bash

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

    # Yet-Another-Bench-Script #

    # v2023-09-06 #

    # https://github.com/masonr/yet-another-bench-script #

    # ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #


    Sa 04 Nov 2023 22:42:47 CET


    Basic System Information:

    ---------------------------------

    Uptime : 5 days, 13 hours, 49 minutes

    Processor : AMD EPYC 7702P 64-Core Processor

    CPU cores : 4 @ 1996.225 MHz

    AES-NI : ✔ Enabled

    VM-x/AMD-V : ❌ Disabled

    RAM : 7.7 GiB

    Swap : 15.7 GiB

    Disk : 148.5 GiB

    Distro : Fedora Linux 38 (Thirty Eight)

    Kernel : 6.5.8-200.fc38.x86_64

    VM Type : KVM

    IPv4/IPv6 : ✔ Online / ❌ Offline


    IPv4 Network Information:

    ---------------------------------

    ISP : netcup GmbH

    ASN : AS197540 netcup GmbH

    Host : netcup GmbH

    Location : Nuremberg, Bavaria (BY)

    Country : Germany


    fio Disk Speed Tests (Mixed R/W 50/50):

    ---------------------------------

    Block Size | 4k (IOPS) | 64k (IOPS)

    ------ | --- ---- | ---- ----

    Read | 139.31 MB/s (34.8k) | 1.13 GB/s (17.6k)

    Write | 139.68 MB/s (34.9k) | 1.13 GB/s (17.7k)

    Total | 279.00 MB/s (69.7k) | 2.27 GB/s (35.4k)

    | |

    Block Size | 512k (IOPS) | 1m (IOPS)

    ------ | --- ---- | ---- ----

    Read | 3.23 GB/s (6.3k) | 3.26 GB/s (3.1k)

    Write | 3.40 GB/s (6.6k) | 3.48 GB/s (3.3k)

    Total | 6.63 GB/s (12.9k) | 6.74 GB/s (6.5k)


    iperf3 Network Speed Tests (IPv4):

    ---------------------------------

    Provider | Location (Link) | Send Speed | Recv Speed | Ping

    ----- | ----- | ---- | ---- | ----

    Clouvider | London, UK (10G) | 1.49 Gbits/sec | 1.86 Gbits/sec | 21.9 ms

    Scaleway | Paris, FR (10G) | 2.00 Gbits/sec | 2.21 Gbits/sec | 19.8 ms

    NovoServe | North Holland, NL (40G) | 2.09 Gbits/sec | 2.26 Gbits/sec | 10.9 ms

    Uztelecom | Tashkent, UZ (10G) | 586 Mbits/sec | 630 Mbits/sec | 96.5 ms

    Clouvider | NYC, NY, US (10G) | busy | 133 Mbits/sec | 92.1 ms

    Clouvider | Dallas, TX, US (10G) | 279 Mbits/sec | 44.4 Mbits/sec | 245 ms

    Clouvider | Los Angeles, CA, US (10G) | 466 Mbits/sec | busy | 170 ms


    Geekbench 6 Benchmark Test:

    ---------------------------------

    Test | Value

    |

    Single Core | 1211

    Multi Core | 3789

    Full Test | https://browser.geekbench.com/v6/cpu/3396437


    YABS completed in 11 min 15 sec


    Wobei die iperf Tests mit Vorsicht zu geniessen sind. Transits, PNIs (zu/über wen auch immer etc) und Peerings etc. also auch Routing hier bitte mit einberechnen.

    Sieht bez. Netz sehr gut aus :thumbup:

    Ja, deswegen erwähnte ich explizit die Domain kannegiesser.net, die vermutlich nichtdeine ist sondern die von Veit_Kannegieser.


    Edit: Bei der Domain scheint sich das DNSSEC Problem mittlerweile in Wohlgefallen aufgelöst zu haben, wie und warum auch immer.

    Interessante Tatsache und ich glaub du hast recht :thumbup:

    Für mich allerdings grade bissl schwierig nachzuvollziehen warum dies den "ausgehenden" DNS Traffic betrifft (er versucht andere "dinge" aufzulösen glaub ich)

    Ich hab keine Frage.

    Wenn er den Host auflösen kann (was von verschiedenen Quellen bei mir funzt) is er trotzdem auf einer anderen ip als die die er ansprechen will wenn er sgplex.de mit 4747 anspricht.

    nan0 hat es oben geschrieben wie er mit der ip und port hinkommt.


    Das Ding meldet sich ja grundsätzlich:

    []$ telnet 202.61.242.104 4747

    Trying 202.61.242.104...

    Connected to 202.61.242.104.

    Escape character is '^]'.

    Connection closed by foreign host.

    Was habe ich denn da verpasst?

    Keine Ahnung, Domain ist derzeit in meinem Besitz und ja, ich finds witzig und mal schauen...

    Und ne, für diese Domain leg ich keine mx, dmarc, spf etc. Einträge an und konfiguriere den Mailserver um eine email an den support zu senden (was natürlich auch bis zu nem gewissen Grad lustig wäre)

    Das wäre zu viel des Guten :)

    Ruhm und Ehre für denjenigen, der zuerst versucht netcup-assimilieren.de zu registrieren – über netcup!


    Es wäre eine Sünde wert. 8o

    Tja es musste sein, ich finde das grade witzig :D

    Natürlich über Netcup registriert, mal schauen was mir da so einfällt :D (Natürlich im "Rahmen"....)


    Chris


    @Edit: Das Datum der nächsten Verrechnung hat sich natürlich nach erfolgreichem Abschluss auf '24 geändert.

    Wenn man sich mit dem Domainhandel aber ein wenig auskennt, hat diese Geschichte einen faden Beigeschmack, denn es ist nicht das erste mal das ein Interessent / Händler eine Geschichte wie diese vorschiebt...

    Es gibt auch noch genug Firmen bzw. Anbieter die "Domain Services" anbieten mit den "damals gezogenen Daten" (diese werden sicher ewig verfügbar bleiben und kommen aus allen möglichen Quellen; sind dann auch Anbieter mit Darknet-search und blabla im Portfolio)


    Ich weiß zwar nicht wie alt bzw. wann die Domain registriert wurde um die es hier geht, kann allerdings sehr wohl eine Möglichkeit sein meines Erachtens nach.