Studia przypadków

Przypadek 1: getty

/bin/sh -x /etc/rc

/rescue/cat -n /etc/rc.conf

exit

echo "coś" > /etc/rc.conf

Przypadek 2: BIND+DNSSEC+splitDNS

• publiczna strefa domena.pl obsługiwana jest przez zewnętrznego operatora DNS,
• lokalny serwer BIND utrzymuje własną wersję tej samej strefy wyłącznie dla sieci LAN,
• w sieci lokalnej domena.pl ma adres prywatny (np. 192.168.1.100),
• w Internecie domena.pl ma adres publiczny (np. 88.x.x.x),
• DNSSEC realizowany jest automatycznie przez
  dnssec-policy default;
  oraz
  inline-signing yes;
  .

1. strefa zwracała SOA, ale nie zwracała rekordu A dla domeny głównej,
2. po restarcie named nie były aktualizowane pliki .signed.

• plik źródłowy został zmodyfikowany,
• BIND widział nowe dane,
• ale aktywna strefa nadal korzystała ze starego pliku podpisanego.

1. Strefa korzystała ze starego pliku .signed.
2. W katalogu pojawiły się pliki .signed.signed, co wskazywało na błędny przebieg podpisywania.
3. Po usunięciu starych plików podpisanych BIND wygenerował je ponownie i załadował aktualną strefę.
4. Rekord A dla domeny głównej wrócił do odpowiedzi DNS.
5. Alias domena.pl.example.pl nie wynikał z błędu strefy, lecz z konfiguracji search w resolverze oraz obecności wildcarda w strefie nadrzędnej.
6. Split DNS działał prawidłowo – problem dotyczył procesu DNSSEC i plików podpisanych, a nie samej koncepcji rozdzielenia DNS publicznego i prywatnego.

Przypadek 3: tworzenie sitemap.xml i 404

W trakcie pracy nad rozbudowaną witryną składającą się z kilkuset statycznych stron HTML wykonano standardową kontrolę techniczną serwisu po wygenerowaniu mapy witryny (sitemap.xml).

Celem było sprawdzenie poprawności indeksacji oraz weryfikacja, czy wszystkie adresy zwracają kod HTTP 200.

Wyniki pozornie były proste — mapa witryny działała, a strona była dostępna. Jednak analiza crawlerem wykazała kilka błędów 404, których lokalizacja w kodzie nie była oczywista.

Po uruchomieniu skanowania narzędziem typu crawler pojawiło się kilka adresów zwracających błąd 404.

Co istotne:

• liczba błędów była niewielka,
• strony jako całość działały poprawnie,
• nie było oczywistego miejsca w HTML, gdzie te adresy były używane.

Problem polegał nie tyle na samej liczbie błędów, co na braku jednoznacznej informacji, skąd one pochodzą.

Naturalnym krokiem jest przeszukanie kodu HTML pod kątem błędnego adresu. W praktyce jednak nie zawsze prowadzi to do rozwiązania problemu.

Odwołania do nieistniejących zasobów mogą znajdować się w różnych miejscach:

• w znacznikach HTML (<img>, <a>, <script>, <link>),
• w CSS (url(...)),
• w JavaScript (dynamiczne przypisania),
• w srcset,
• w szablonach wspólnych dla wielu podstron,
• w sitemap.xml.

W efekcie ręczne przeszukiwanie pojedynczych plików często nie daje natychmiastowego wyniku.

Jednym z pierwszych kroków powinna być analiza samej mapy witryny.

W wielu przypadkach błędy 404 wynikają z:

• pozostawienia starych adresów w sitemap.xml,
• nieaktualnych wpisów po zmianie struktury serwisu,
• błędów generowania mapy przez automatyczne narzędzia.

Każdy adres w sitemap.xml powinien zwracać kod HTTP 200. Jeśli tak nie jest, mapa witryny wprowadza w błąd mechanizmy indeksujące oraz narzędzia analityczne.

W trakcie analizy okazało się, że duża część trudności nie wynikała z samej witryny, ale z narzędzi używanych do jej analizy.

Różne narzędzia dawały różne rezultaty:

• jedno wykrywało błędy 404,
• inne nie raportowało ich wcale,
• jeszcze inne znajdowało adresy, które nie występowały w kodzie.

Brak spójności utrudniał jednoznaczną ocenę sytuacji.

Część narzędzi wskazywała jedynie adres 404, bez informacji:

• na której stronie występuje odwołanie,
• w którym elemencie został znaleziony link.

Powodowało to konieczność ręcznego przeszukiwania całej struktury serwisu.

Nie wszystkie wykryte adresy pochodziły bezpośrednio z treści strony.

Część była generowana przez:

• CSS (np. obrazy tła),
• JavaScript (dynamiczne przypisania),
• elementy ładowane warunkowo,
• stare wpisy w zasobach statycznych.

W efekcie część błędów nie miała „widocznego” miejsca w HTML.

Dodatkowym źródłem niejednoznaczności był sam generator sitemap.xml, który:

• potrafił utrzymywać nieaktualne URL-e,
• nie zawsze odświeżał strukturę po zmianach,
• czasami bazował na danych historycznych.

W rezultacie mapa witryny mogła zawierać adresy, które nie były już częścią aktualnej struktury serwisu.

Analiza przypadku prowadzi do kilku wniosków:

• żadne pojedyncze narzędzie nie daje pełnego obrazu stanu serwisu,
• wyniki crawlerów należy traktować jako punkt wyjścia, a nie ostateczną prawdę,
• każdy błąd 404 wymaga weryfikacji źródła, a nie tylko samego adresu,
• sitemap.xml musi być traktowana jako element aktywny, a nie jednorazowo wygenerowany plik.

W praktyce nawet niewielka liczba błędów może wskazywać na pozostałości po wcześniejszych zmianach w strukturze strony.

W środowisku rozbudowanych serwisów statycznych najtrudniejszym elementem nie jest samo wykrycie błędu, ale jego poprawna interpretacja.

Crawler i sitemap są narzędziami pomocniczymi — przydatnymi, ale nieomylne dane trzeba zawsze potwierdzić w kodzie źródłowym oraz strukturze serwera.

Dopiero połączenie analizy narzędziowej i ręcznej weryfikacji pozwala uzyskać pełny obraz stanu technicznego witryny.

Przypadek 4: sitemap - a co widzi Google

W praktyce administracji stron WWW bardzo często pojawia się uproszczenie: „mam sitemapę, więc Google wie wszystko o mojej stronie”. To jedno z tych zdań, które brzmią sensownie, ale w realnym świecie technicznym są tylko częściowo prawdziwe.

Sitemap XML nie jest mapą w sensie diagnostycznym. To jest raczej lista adresów URL przekazana robotowi wyszukiwarki. Google dostaje informację: „te strony istnieją”. Ale to nie oznacza, że te strony są poprawne, dostępne, dobrze połączone albo wartościowe w strukturze serwisu.

Plik sitemap.xml pełni jedną funkcję: pokazuje robotowi wyszukiwarki, jakie adresy URL powinny zostać uwzględnione w indeksowaniu. I to wszystko.

Nie sprawdza on:

• czy strona zwraca błąd 404,
• czy linki wewnętrzne prowadzą do istniejących zasobów,
• czy struktura serwisu jest logiczna,
• czy dana podstrona jest osierocona (orphan page).

Sitemap jest więc bardziej deklaracją niż analizą. Można powiedzieć, że to „spis treści”, ale bez sprawdzania, czy wszystkie rozdziały nadal istnieją.

Zupełnie inną klasą narzędzi są crawlery. To one działają podobnie do Googlebota: przechodzą po stronie link po linku i sprawdzają jej rzeczywisty stan.

Crawler:

• odwiedza każdą stronę jak użytkownik lub bot,
• analizuje odpowiedzi serwera (200, 301, 404, 500),
• wykrywa zerwane linki,
• mapuje strukturę połączeń między podstronami.

Dopiero na podstawie takiego skanu można powiedzieć coś o „zdrowiu” strony, a nie tylko o jej liście adresów.

W trakcie crawlowania często pojawiają się tzw. broken links (np. 404). Wbrew popularnemu podejściu nie są one automatycznie problemem krytycznym dla SEO. Google nie „karze” za pojedyncze błędy tego typu.

Problem zaczyna się dopiero wtedy, gdy:

• błędy występują w linkach wewnętrznych,
• struktura strony opiera się na nieistniejących zasobach,
• architektura linkowania stopniowo się rozjeżdża.

Wtedy nie chodzi już o pojedyncze błędy, ale o degradację spójności całego serwisu.

W praktyce te dwa podejścia często są mylone, bo wiele narzędzi łączy je w jednym interfejsie. Ale funkcjonalnie to są dwa różne światy:

• sitemap mówi: „co powinno istnieć”
• crawler mówi: „co faktycznie działa”

I dopiero zestawienie tych dwóch perspektyw daje realny obraz strony.

W przypadku stron średniej wielkości (kilkaset do kilku tysięcy podstron) często zaczyna się moment, w którym sama sitemap przestaje być wystarczająca jako narzędzie kontroli.

Pojawia się wtedy potrzeba spojrzenia na stronę jak Googlebot:

• przez crawl,
• przez analizę linków,
• przez weryfikację struktury, a nie tylko listy URL.

I to jest moment, w którym SEO techniczne zaczyna mieć większe znaczenie niż sama obecność sitemapy.

Przypadek 5: DNSSEC i zarządzanie domeną

DNSSEC w teorii jest prostym mechanizmem: podpisujemy strefę DNS, publikujemy rekordy kryptograficzne i zyskujemy ochronę przed podszywaniem się pod odpowiedzi DNS. W praktyce jednak wdrożenie w środowisku hostingowym pokazuje, że największym problemem nie jest sama technologia, ale model zarządzania domeną.

Celem było sprawdzenie, czy DNSSEC można włączyć w typowej konfiguracji: domena krajowa (.pl), DNS zarządzany przez dostawcę hostingu, bez własnej infrastruktury DNS.

Pierwszym krokiem była kontrola delegacji zabezpieczeń:

dig domena.pl DS

Brak rekordu DS w odpowiedzi oznacza brak aktywnego DNSSEC po stronie rejestru.

Następnie sprawdzono strefę DNS:

• brak rekordów DNSKEY
• brak podpisów RRSIG

Wniosek był jednoznaczny: strefa DNS nie jest podpisana, a DNSSEC nie jest aktywny.

W środowiskach hostingowych często nie ma bezpośredniego przełącznika DNSSEC w panelu użytkownika, mimo że:

• DNS jest w pełni zarządzany z poziomu hostingu,
• strefa DNS działa poprawnie,
• rekordy można dowolnie edytować.

Brakuje jednak elementu kluczowego: publikacji rekordu DS w rejestrze domeny.

DNSSEC nie jest usługą „po stronie hostingu DNS”, tylko elementem łańcucha zależności:

rejestr domeny → delegacja DS → serwery DNS → podpisana strefa

Oznacza to, że:

• poprawna konfiguracja DNS nie gwarantuje DNSSEC,
• panel hostingu nie zawsze daje pełną kontrolę nad bezpieczeństwem domeny,
• aktywacja często wymaga działania po stronie rejestratora lub wsparcia technicznego.

DNSSEC w praktyce ujawnia typowy problem infrastruktury DNS: rozdzielenie odpowiedzialności.

Z punktu widzenia administratora:

• DNSSEC nie jest „ustawieniem”, tylko procesem w łańcuchu usług,
• brak jednego elementu (DS) unieważnia całą konfigurację,
• a widoczność w panelach hostingowych bywa myląca.

W efekcie technologia, która ma zwiększać bezpieczeństwo, często okazuje się trudna nie dlatego, że jest skomplikowana, ale dlatego, że jest rozproszona między różne systemy.

Przypadek 6: sprzętowe wybory - komputer dla OPNsense

Dobór sprzętu do nowoczesnego firewalla opartego o OPNsense przestał być prosty. W praktyce nie wybiera się już „routera”, tylko mały serwer brzegowy (edge firewall).

W analizowanym przypadku celem było zbudowanie urządzenia:

• z systemem OPNsense (FreeBSD)
• obsługą 2.5G (LAN)
• uplinkiem 10G (WAN/backbone)
• minimum 6× Intel i226-V (interfejsy LAN)
• RAM 8–16 GB
• stabilnością 24/7
• budżetem ~1500–2000 zł

W urządzeniach klasy AliExpress (CWWK / Topton / OEM):

• karta sieciowa (Intel i226-V) jest stała
• RAM i SSD są drugorzędne
• CPU definiuje realną klasę firewalla

Największe obciążenia nie wynikają z NAT, ale z:

• VPN (WireGuard / OpenVPN)
• IDS/IPS (Suricata / Zenarmor)
• burst traffic (szczytowe obciążenia 2.5G–10G)

• niska wydajność
• brak zapasu CPU
• tylko podstawowy NAT/firewall

👉 wniosek: nie nadają się do 2.5G

• bardzo niski pobór energii
• dobra efektywność per Watt
• ograniczona wydajność szczytowa

👉 wniosek:

świetne do routera, ale ograniczone pod IDS i VPN przy dużym ruchu

• wyższy single-core performance
• lepszy VPN throughput
• większy zapas CPU
• stabilniejsza praca przy IDS

👉 wniosek:

najlepsza klasa dla firewalla 2.5G+ z zapasem

W toku analizy wybrano docelową konfigurację:

 Intel i5-1235U + 6× Intel i226-V + 2× 10GbE uplink

• WAN: 2×10G (uplink / ISP / backbone / agregacja)
• LAN: 6×2.5G Intel i226-V (segmentacja VLAN / DMZ / LAN)
• CPU: Intel i5-1235U
• RAM: 16 GB DDR4
• Storage: NVMe SSD

i5-1235U oferuje:

• wysoką wydajność single-core (VPN, routing)
• 10 rdzeni (P + E cores)
• stabilny throughput przy obciążeniu IDS
• duży zapas CPU

👉 klucz:

firewall musi mieć headroom, nie tylko „peak performance”

• 2×10G → uplink / backbone
• 6×2.5G → segmentacja LAN

👉 efekt:

• brak bottlenecku na interfejsach
• brak przeciążeń przy VLAN

• Intel i226-V → driver igc
• stabilna obsługa OPNsense 24+
• sprawdzona platforma firewall

• brak swap przy IDS
• stabilne logowanie
• buffer dla Suricata / Zenarmor

Mimo dobrych parametrów energetycznych:

• N300 / N305 / N355 mają ograniczony single-core
• IDS i VPN są CPU-bound
• przy 10G i dużym ruchu brakuje headroomu

👉 wniosek:

N-series = edge router
i5-1235U = edge firewall

W firewallach 2.5G–10G nie wygrywa najniższy pobór energii, tylko stabilny zapas CPU przy szczytowym obciążeniu (VPN + IDS + routing).

• i5-1235U + 6× i226-V + 2×10G

• N355

• N305

• i3-5010U
• i3-8140U
• N300

Dobór sprzętu firewall w tej klasie nie polega na wyborze „najmocniejszego CPU”, tylko na znalezieniu punktu, w którym:

• CPU nie jest bottleneckiem przy burst traffic
• IDS nie zatyka systemu
• VPN utrzymuje stabilny throughput
• sieć 2.5G/10G nie powoduje throttlingu

Introduction and Environment Context

• Operating System: FreeBSD (amd64 architecture)
• File System: UFS2 (classic partition layout, including separate mount points for / and /usr)
• Additional Services: Active jail containers managed from the host system.

1. Failure Symptoms (Primary Symptoms)

After a machine reboot, the system failed to enter the normal Multi-User mode and fell into a loop of critical text console errors:

1. Getty Loop: The screen was massively flooded with the message:

   init: cant exec getty /usr/libexec/getty for port /dev/ttyv0: no such file or directory

   followed by:

   getty repeating too quickly on port ttyv0, sleeping 30 secs.

   This symptom affected all virtual consoles from ttyv0 to ttyv7.
2. Single-User Mode Failure: Attempts to enter Single-User mode to repair the configuration resulted in a repeating message:

   cannot read termcap database.

   This prevented standard text shells and advanced text editors (e.g., vi) from functioning properly, forcing operation in dumb terminal mode.
3. "Amnesiac" Status: In rare moments when the system allowed interaction in Multi-User mode, it identified itself under the default kernel name: amnesiac. Access to the /usr/bin/login program was completely missing, and network interfaces as well as jail containers remained inactive.

2. Diagnostic Chronology and Blind Alleys (Successive Troubleshooting Attempts)

Attempt 1: Suspected Corruption of System Binaries and the Termcap Database

• Hypothesis: The /usr/libexec/getty file or the /usr/share/misc/termcap database suffered physical corruption, deletion, or truncation (EOF error) during jail operations or a failed update.
• Action: Manually replaced the getty file and termcap database from a working machine with the identical system version. Rebuilt the database using the command:

  cap_mkdb

  .
• Result: No effect. Despite the physical presence of files with correct permissions (root:wheel, 755/644), the system continued to report them as missing (No such file or directory).

Attempt 2: Suspected Dynamic Library Failure (Linker Error)

• Hypothesis: A "No such file or directory" message in UNIX systems when the executable file exists often indicates a missing dynamic linker or associated .so libraries.
• Action: Replaced key system libraries: libc.so.7, libutil.so.9, and libsys.so.7. Checked dependencies using ldd and the ELF header using the command:

  objdump -p

  .
• Result: Another false lead. The getty file proved functional, and ldd showed no missing dependencies (the "not found" status disappeared), yet the kernel still refused to execute the program.

Attempt 3: Attempting a Forced Repair and Update via freebsd-update

• Hypothesis: Deep file structure corruption (e.g., via permission leakage from a jail to the host). An automated tool should restore consistency.
• Action: Brought up the network in Single-User mode (dhclient, manual routing, and DNS configuration in /etc/resolv.conf) to execute

  freebsd-update fetch install

  or

  freebsd-update IDS

  .
• Result: Failure. The freebsd-update tool aborted with a generic and misleading error stating it only supports Tier 1 architectures, triggered by the operating environment inconsistency within RAM.

Attempt 4: Analysis of the Mount Table and Root Directory Permissions

• Hypothesis: The /usr partition is mounting in read-only (ro) mode, or kernel path pointers (vnodes/nullfs leakage) were corrupted by improperly stopped jails.
• Action: Verified the /etc/fstab file and executed commands

  mount -u /

  and

  mount -a

  . Attempted to move getty and the termcap database to the root partition / to bypass the /usr structure.
• Result: Partial success. Bypassing the /usr path allowed the system to boot without the error loop, but revealed a deeper symptom – the system booted as amnesiac and continued to ignore disk mounting in Multi-User mode. Typing exit immediately dropped the system back into Single-User mode.

3. Breakthrough and True Cause Identification

The key to solving the puzzle was tracing the boot sequence script line-by-line using the built-in sh shell debugging mechanism in Single-User mode:

/bin/sh -x /etc/rc

Test Result: The /etc/rc script initiated execution, loaded basic variables, and then suddenly and silently terminated (exit 0), completely halting the remaining boot procedure. Further verification via:

/rescue/cat -n /etc/rc.conf

revealed anomalies. At the very end of the /etc/rc.conf configuration file sat a single, hidden command:

exit

How did this happen? This word was most likely accidentally written to the file during an SSH session (e.g., via an incorrect stream redirection

echo "something" > /etc/rc.conf

4. Why Did This Single Line Trigger Such a Spectacular Cascade of Errors? (Technical Analysis)

In FreeBSD, the /etc/rc.conf file is not a passive configuration file (like .ini or .json files). It is executed via sourcing (using the dot or source command) inside the primary startup script /etc/rc. Injecting the word exit into rc.conf caused the following sequence:

1. The main system process (init) invoked /etc/rc.
2. The /etc/rc script read /etc/rc.conf in its first lines.
3. The interpreter encountered the exit instruction inside rc.conf and instantly terminated the entire /etc/rc process.
4. Consequently, the system never executed the subsequent boot steps:
   • The hostname and network parameters were not set (hence the amnesiac status).
   • The script responsible for mounting disks from the /etc/fstab table was never run (the /usr partition remained physically unmounted in Multi-User mode).
5. When init proceeded to the next phase and attempted to spawn login screens from the /etc/ttys file, it queried the unmounted /usr partition for the /usr/libexec/getty program. Since the directory was empty, the kernel returned a "No such file or directory" error, provoking the "repeating too quickly" restart loop.

5. Resolution (Remedium)

Repairing the system required completely bypassing the corrupted configuration and restoring consistency from a clean, static rescue shell:

1. Booted the system into Single-User mode.
2. Invoked a fully independent rescue shell (which does not rely on dynamic libraries):

   Enter full pathname of shell: /rescue/sh

3. Mounted the root partition in write mode:

   /rescue/mount -u /

4. Removed the faulty line from the configuration file (using

   /rescue/ee /etc/rc.conf

   or automatically via sed).
5. Restored the stock, clean terminal configuration file /etc/ttys using the fetch tool.
6. Executed

   /rescue/reboot

   .

Once the exit word was removed, the /etc/rc script executed completely, automatically mounting all UFS2 partitions, bringing up the network, and restoring proper getty functionality across all consoles.

Lessons for Administrators (Takeaway)

• Verify the source, not the symptoms: The avalanche of binary errors (getty, termcap, ldd) was merely a domino effect caused by the unmounted /usr partition.
• Remember the nature of rc.conf: In BSD-family systems, configuration files are part of the shell code. A syntax error or an injected control command within a configuration file directly compromises the stability of the professional init process.
• /rescue tools save lives: In critical moments of shared environment inconsistency, the statically linked binaries within the /rescue directory remain the administrator's only reliable point of leverage.

## Problem Description

The administrator maintains a custom DNS server based on BIND 9.20 on FreeBSD.

The initial assumptions were as follows:

• the public zone domena.pl is handled by an external DNS operator,
• the local BIND server maintains its own version of the same zone exclusively for the LAN network,
• in the local network, domena.pl points to a private address (e.g., 192.168.1.100),
• on the Internet, domena.pl points to a public address (e.g., 88.x.x.x),
• DNSSEC is automatically implemented via

  dnssec-policy default;

  and

  inline-signing yes;

  .

Following configuration changes, two issues appeared simultaneously:

1. the zone returned the SOA record, but failed to return the A record for the apex/root domain,
2. after restarting named, the .signed files were not being updated.

# Symptoms

The local DNS server responded to queries as follows:

dig @192.168.1.1 domena.pl A

output:

status: NOERROR
ANSWER: 0
AUTHORITY: 1
domena.pl. IN SOA ns1.example.pl. hostmaster.example.pl.

Missing A record despite the entry being present:

@ IN A 192.168.1.100

inside the zone file.

Concurrently:

named-checkzone domena.pl domena.pl.zone.db

returned:

loaded serial XXXXX
OK

which indicated that the source file itself was correct.

# First Lead – The Zone Is Not Using the Up-to-Date File

The command:

rndc zonestatus domena.pl

showed:

file: domena.pl.zone.db.signed
serial: 202407013
signed serial: 202407376

whereas:

named-checkzone domena.pl domena.pl.zone.db

displayed a newer serial number:

2026060105

This indicated that:

• the source file had been modified,
• BIND detected the new data,
• but the active zone was still utilizing the old, signed file.

# Additional Complication – The .signed.signed Files

The following files appeared in the zone directory:

domena.pl.zone.db.signed
domena.pl.zone.db.signed.jbk
domena.pl.zone.db.signed.signed
domena.pl.zone.db.signed.signed.jnl

This is a typical symptom of a situation where:

file "domena.pl.zone.db.signed";
inline-signing yes;

BIND attempts to sign an already signed zone. As a result, subsequent nested layers are created:

.signed
.signed.signed

which leads to chaos and misleads diagnostics.

# Correct inline-signing Configuration

For automated DNSSEC, the zone file directive should point strictly to the raw source file:

zone "domena.pl" {
type primary;
file "/path/to/domena.pl.zone.db";
dnssec-policy default;
inline-signing yes;
allow-update { none; };
};

You must not specify:

file "domena.pl.zone.db.signed";

as the source file for the zone configuration.

# Resolution

After correcting the configuration, the following commands were executed:

service named stop

the old files were removed:

rm domena.pl.zone.db.signed*

and then:

service named start

Upon startup, BIND automatically generated new files:

domena.pl.zone.db.signed
domena.pl.zone.db.signed.jbk

and successfully loaded the up-to-date contents of the zone.

Verification query:

dig @192.168.1.1 domena.pl A +short

output:

192.168.1.100

The issue was resolved.

# The Second Issue – Strange domena.pl.example.pl Name Resolution

The command:

nslookup domena.pl 8.8.8.8

returned:

Aliases: domena.pl.example.pl

which suggested a DNS misconfiguration.

Upon analysis, it turned out that:

cat /etc/resolv.conf

contained:

search example.pl

and the public example.pl zone featured the following record:

*.example.pl CNAME example.pl

Consequently, the resolver attempted to automatically append the search suffix:

domena.pl → domena.pl.example.pl

and the wildcard record responded with a valid answer. This was not a DNS error within the domena.pl zone itself, but rather a side effect of the search domain mechanism.

# Split DNS – Proper Interpretation

In this scenario, the administrator intentionally maintained two distinct versions of the same domain:

## Public DNS

domena.pl -> 88.x.x.x

maintained by an external operator.

## Local DNS

domena.pl -> 192.168.1.100

maintained by the local BIND server.

This is a classic split DNS setup and in itself does not constitute an error.

# Should "search example.pl" Be Removed?

Not necessarily. If the administrator relies on short hostnames:

ssh server1
ping nas
ping backup

then the directive:

search example.pl

is highly useful. However, it must be kept in mind that it triggers automatic name expansion:

host → host.example.pl

and

domena.pl → domena.pl.example.pl

whenever the resolver determines that the requested name is not fully qualified (FQDN).

# Should the Wildcard *.example.pl Be Removed?

Not in every case. The wildcard record:

*.example.pl CNAME example.pl

is frequently used to route various hosted services, such as:

jellyfin.example.pl
grafana.example.pl
nextcloud.example.pl

Removing it might break access to multiple existing subdomains. Prior to deletion, verify whether it is currently utilized by live services.

# Conclusions

The primary root causes of the issue were identified as follows:

1. The zone was utilizing an outdated .signed file instance.
2. The appearance of .signed.signed files in the directory pointed to a broken zone-signing process loop.
3. After purging the legacy signed assets, BIND successfully re-generated them and loaded the current zone data.
4. The apex domain A record successfully returned to the DNS responses.
5. The domena.pl.example.pl alias did not stem from a zone configuration flaw, but from the search directive in the resolver combined with a wildcard entry in the parent zone.
6. The split DNS mechanism functioned correctly – the breakdown exclusively affected the DNSSEC validation sequence and signed zone files, not the actual public/private DNS separation concept.