Portál AbcLinuxu, 6. května 2025 11:40
Řešení dotazu:
12:47:26.277334 IP X.12033 > c.gtld-servers.net.domain: 48675% [1au] A? miat.com. (37) 12:47:26.277555 IP X.36698 > m.gtld-servers.net.domain: 41093% [1au] AAAA? miat.com. (37) 12:47:26.277660 IP X.23231 > i.gtld-servers.net.domain: 42459% [1au] MX? miat.com. (37) 12:52:47.272427 IP X.57694 > ns4-208.azure-dns.info.domain: 37846% [1au] TXT? selector1-batashoeorganization-onmicrosoft-com._domainkey.batashoeorganization.onmicrosoft.com. (123) 12:52:47.314011 IP ns4-208.azure-dns.info.domain > X.57694: 37846*- 1/0/1 TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCrZKTAXRNPuqgg2V82jK+050KRORyjEBmZWDbDZPTVDhEsls+//jta3VrKs2ONzQXrb4OWcGXFOupWCroQ+W5Ymo5sX92QeXIvYeNKWuJ2AxxqffFgde1KtU00w+YyH4pCwFMVjBh+c9VMJt09eKbYzJw8CBocqDGT4MfcV5AgfQIDAQAB;" (371)Kdyz zakazu pristup na dns, tak zatim jsem si vsiml, ze dkim timeoutuje, ale nemam stopro jistotu, ze je to jen timhle. Provereni dkim/postfix na nastaveni resolvingu - vse je na default z balicku, cili dns...
tipol by som ze lsof alebo ss alebo ked nie autitctl tak systemtap to urcite chytia
D>
sendmsg()
i connect()
, protože je na aplikaci, jestli použije connected socket nebo ne.
socket()
to nepoznáte, (2) connect()
tam nemusí být a hlavně (3) na použití strace byste potřeboval vědět, který proces vás zajímá - což je přesně ta informace, kterou se tazatel snaží zjistit.
root@stroj~# netstat -tupan tcp 0 0 0.0.0.0:111 0.0.0.0:* NASLOUCHÁ 547/rpcbind … tcp6 0 0 :::111 :::* NASLOUCHÁ 547/rpcbind … udp 0 0 0.0.0.0:111 0.0.0.0:* 547/rpcbind … udp6 0 0 :::111 :::* 547/rpcbind … udp6 0 0 :::723 :::* 547/rpcbind …Vylistování procesů používajících určité číslo portu:
root@stroj~# lsof -i :111 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rpcbind 547 root 6u IPv4 17986 0t0 UDP *:sunrpc rpcbind 547 root 8u IPv4 17087 0t0 TCP *:sunrpc (LISTEN) rpcbind 547 root 9u IPv6 17088 0t0 UDP *:sunrpc rpcbind 547 root 11u IPv6 17090 0t0 TCP *:sunrpc (LISTEN)
ss -nup dport == :53
". Jenže problém je v tom, že na DNS dotaz, který typicky obnáší jeden paket s dotazem a jeden paket s odpvoědí, nepotřebujete connected socket a i když ho aplikace použije, stejně nemáte záruku, že se trefíte zrovna do toho krátkého okna, když ten socket bude existovat a bude connected.
resolv.conf
. To máte resolv.conf nakonfigurovaný tak, že DNS názvy překládáte pomocí DNS serveru, který běží na jiném portu, než 53? Nebo dokonce používáte jiný protokol? Můžete uvést, jak konkrétně máte resolv.conf
nastavený?
search domain.tld nameserver X.X.X.X nameserver Y.Y.Y.YX/Y jsou na stejnem subnetu jako dns servery.
/etc/resolv.conf
, ale ještě je potřeba zjistit, zda resolver tuto konfiguraci používá.
hosts: files dns networks: filesVzhledem k bodu a] lokalni resolver funguje spravne.
Nameservers (string)
Provides a comma-separated list of IP addresses that are to be used when doing DNS queries to retrieve DKIM keys, VBR records, etc. These override any local defaults built in to the resolver in use, which may be defined in /etc/resolv.conf or hard-coded into the software.
Takze jeste jednou.To není „ještě jednou“, to poprvé píšete informace, které měly být už v původním dotazu. OK, informace o konfiguraci systému zveřejňovat nechcete a máte nějaký důvod myslet si, že problém je v nějaké aplikaci a ne v resolveru. Vzhledem k tomu, že máte nějakou nestandardní konfiguraci Debianu 8, je docela odvážné takhle rovnou odstřihnout jednu ze dvou možných příčin problému, ale to je váš problém. Pak mi jako nejpoužitelnější řešení připadá to výše uvedené s logováním paketů spolu s identifikátorem procesu v iptables – a pokud vám příslušný modul v iptables chybí, budete ho asi muset doinstalovat.
resolv.conf
, je založena na nějakých vstupních informacích, které uvedeny nebyly, a je chybná. Resolver, tedy proces/knihovna, který se dotazuje DNS, by měl být funkční jen jeden v systému. Žádná z těch aplikací vlastní resolving nedělá, aplikace požádá resolver, aby lookup vyřešil a vrátil výsledek. Problém by mohl být v tom, že z nějakého důvodu jsou funkční dva resolvery s jinou konfigurací, i když moc nevím jak. Možná současně je uveden externí DNS systém v resolv.conf
a současně cachující rekurzivní DNS server běžící na systému. Ale zatím je to věštění z křištálové koule. Na analýzu by bylo potřeba popsat problém, co se skutečně děje. A výpisy resolv.conf
, ps -ef
, a popřípadě záchyt tcpdump
s cílovým portem 53.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.