BIND nepřekládá některé domény

[ktk]

Tak jsem se konecne dostal k tomu logovani, premluvil (rozumej vypnul) apparmor, aby mohl bind zapisovat ty logy, a tady je vysledek, ze ktereho teda nejsem moc moudrej:

kdyz dignu www.ebay.com, dostanu zas jen cname, to je ocekavane, zapnuty logovani to nespravi:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @192.168.2.1 www.ebay.com

; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.2.1 www.ebay.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14936
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b7aced9d9ab8c81801000000617a7e3dd7318e8005bc73a3 (good)
;; QUESTION SECTION:
;www.ebay.com. IN A

;; ANSWER SECTION:
www.ebay.com. 300 IN CNAME slot9428.ebay.com.edgekey.net.

;; Query time: 103 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Čt říj 28 12:41:01 CEST 2021
;; MSG SIZE  rcvd: 112

v resolver.log je:

Kód: [Vybrat]

28-Oct-2021 12:41:01.773 fetch: www.ebay.com/A
28-Oct-2021 12:41:01.853 fetch: ebay.com/DS
28-Oct-2021 12:41:01.873 fetch: slot9428.ebay.com.edgekey.net/A

a v queries.log:

Kód: [Vybrat]

28-Oct-2021 12:41:01.773 client @0x7f799c00b6a8 192.168.2.22#58767 (www.ebay.com): query: www.ebay.com IN A +E(0)K (192.168.2.1)
28-Oct-2021 12:41:02.421 client @0x7f7998030468 192.168.2.10#46210 (1.pool.ntp.org): query: 1.pool.ntp.org IN A + (192.168.2.1)
28-Oct-2021 12:41:02.421 client @0x7f79980347b8 192.168.2.10#46210 (1.pool.ntp.org): query: 1.pool.ntp.org IN AAAA + (192.168.2.1)

Z toho ty dotazy na ntp.org budou pocitam z jinych zarizeni v siti.

Vidite z toho nekdo neco, co ja ne?

[Reklama]

[Filip Jirsák]

Ten Bind je nakonfigurovaný, aby dotazy vyřizoval sám, nebo je přeposílá na nějaký nadřazený DNS resolver, třeba ten od ISP? Jaké dotazy Bind skutečně odešle a jaké odpovědi dostane? Odchytil bych dotazy a odpovědi na vnějším rozhraní tcpdumpem, ať víme, jaká komunikace tam doopravdy probíhá.

[ktk]

Mel by forwardovat DNS od ISP a k tomu pridat jednu virtualni domenu, ktera ma fungovat jen u me doma. Je to podrobneji popsane na zacaktu vlakna.

ten tcpdump na rozhrani smerem ven k ISP, kdyz zkusim dig z lokalni site, mi rika tohle:

Kód: [Vybrat]

13:32:09.226007 IP ktk.unhfree.czf.36055 > ns.unhfree.czf.domain: 48141+% [1au] A? www.ikea.com. (53)
13:32:09.241766 IP ns.unhfree.czf.domain > ktk.unhfree.czf.36055: 48141 4/0/1 CNAME san.ev11958.ikea.com.edgekey.net., RRSIG, CNAME e11958.x.akamaiedge.net., A 104.64.121.234 (241)
13:32:09.242207 IP ktk.unhfree.czf.47857 > ns.unhfree.czf.domain: 28297+% [1au] DNSKEY? ikea.com. (49)
13:32:09.246074 IP ns.unhfree.czf.domain > ktk.unhfree.czf.47857: 28297 3/0/1 DNSKEY, DNSKEY, RRSIG (301)
13:32:09.247534 IP ktk.unhfree.czf.54014 > ns.unhfree.czf.domain: 38580+% [1au] DS? ikea.com. (49)
13:32:09.253121 IP ns.unhfree.czf.domain > ktk.unhfree.czf.54014: 38580$ 3/0/1 DS, DS, RRSIG (316)
13:32:09.256384 IP ktk.unhfree.czf.38279 > ns.unhfree.czf.domain: 47353+% [1au] A? san.ev11958.ikea.com.edgekey.net. (73)
13:32:09.268401 IP ns.unhfree.czf.domain > ktk.unhfree.czf.38279: 47353 NXDomain* 0/0/1 (61)

tady je ten dig:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @192.168.2.1 www.ikea.com

; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.2.1 www.ikea.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8764
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: e843ef420a4b72b301000000617a8a3984c60853b5bd23a5 (good)
;; QUESTION SECTION:
;www.ikea.com. IN A

;; ANSWER SECTION:
www.ikea.com. 85725 IN CNAME san.ev11958.ikea.com.edgekey.net.

;; Query time: 71 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Čt říj 28 13:32:09 CEST 2021
;; MSG SIZE  rcvd: 115


[Filip Jirsák]

Kód: [Vybrat]

13:32:09.268401 IP ns.unhfree.czf.domain > ktk.unhfree.czf.38279: 47353 NXDomain* 0/0/1 (61)


Tohle je divné, ten server unhfree.czf vám vrací, že záznam neexistuje. Zkuste pomocí dig dotaz přímo na ten server ns.unhfree.czf, jestli dostanete stejnou odpověď.

[ktk]

To pak dostanu korektni odpoved.
hele:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @10.98.231.66 www.ikea.com

; <<>> DiG 9.16.1-Ubuntu <<>> @10.98.231.66 www.ikea.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18034
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.ikea.com. IN A

;; ANSWER SECTION:
www.ikea.com. 82552 IN CNAME san.ev11958.ikea.com.edgekey.net.
san.ev11958.ikea.com.edgekey.net. 20864 IN CNAME e11958.x.akamaiedge.net.
e11958.x.akamaiedge.net. 20 IN A 104.64.121.234

;; Query time: 35 msec
;; SERVER: 10.98.231.66#53(10.98.231.66)
;; WHEN: Čt říj 28 14:25:02 CEST 2021
;; MSG SIZE  rcvd: 137

ktk@ktk-OptiPlex-7060:~$
Tcpdump pak rika tohle:

Kód: [Vybrat]

root@router:/home/ktk# tcpdump -i enp3s0 udp port 53 or tcp port 53 
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:25:54.289641 IP ktk.unhfree.czf.40468 > ns.unhfree.czf.domain: 41717+ [1au] A? www.ikea.com. (53)
14:25:54.302271 IP ns.unhfree.czf.domain > ktk.unhfree.czf.40468: 41717 3/0/1 CNAME san.ev11958.ikea.com.edgekey.net., CNAME e11958.x.akamaiedge.net., A 104.64.121.234 (137)
14:25:54.305107 IP ktk.unhfree.czf.60189 > ns.unhfree.czf.domain: 39880+ PTR? 66.231.98.10.in-addr.arpa. (43)
14:25:54.322334 IP ns.unhfree.czf.domain > ktk.unhfree.czf.60189: 39880 1/0/0 PTR ns.unhfree.czf. (71)
14:25:54.322503 IP ktk.unhfree.czf.46750 > ns.unhfree.czf.domain: 39702+ PTR? 98.250.98.10.in-addr.arpa. (43)
14:25:54.330580 IP ns.unhfree.czf.domain > ktk.unhfree.czf.46750: 39702 1/0/0 PTR ktk.unhfree.czf. (72)

Cely to je zas popsany na zacatku vlakna - kdyz se zeptam DNS od ISP, dostanu korektni opdpoved. kdyz routeru-myho bindu, dostanu jen CNAME, ale dal nic. A kdyz nekoho v domaci siti, kdo ma ten bind pouzivat jako DNS nedostanu ani ten CNAME.

Trosku to smrdi jakoby nejakym ttl, jestli v dns neco podobnyho existuje.

[Reklama]

[Filip Jirsák]

Tohle je ale jiná komunikace. Zeptejte se na ten název san.ev11958.ikea.com.edgekey.net, na který se ptá Bind.

[ktk]

Hmm, to uz je zajimave, na tohle jmeno uz taky da NXDOMAIN:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @10.98.231.66 san.ev11958.ikea.com.edgekey.net

; <<>> DiG 9.16.1-Ubuntu <<>> @10.98.231.66 san.ev11958.ikea.com.edgekey.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;san.ev11958.ikea.com.edgekey.net. IN A

;; Query time: 4 msec
;; SERVER: 10.98.231.66#53(10.98.231.66)
;; WHEN: Čt říj 28 14:41:04 CEST 2021
;; MSG SIZE  rcvd: 61


Kód: [Vybrat]

14:41:04.486619 IP (tos 0x0, ttl 63, id 11111, offset 0, flags [none], proto UDP (17), length 101)
    ktk.unhfree.czf.51196 > ns.unhfree.czf.domain: 47232+ [1au] A? san.ev11958.ikea.com.edgekey.net. (73)
14:41:04.489379 IP (tos 0x0, ttl 62, id 64623, offset 0, flags [none], proto UDP (17), length 89)
    ns.unhfree.czf.domain > ktk.unhfree.czf.51196: 47232 NXDomain* 0/0/1 (61)


[Filip Jirsák]

Vidím tam akorát rozdíl, že Bind dostává odpověď s DNSSEC, zatímco ten dotaz z vaší sítě dostává odpověď bez DNSSEC. Ale rozdíl v dotazu tam žádný nevidím, možná by bylo něco vidět v nějakém podrobnějším výpise.

Každopádně mi ale připadá divné to chování serveru unhfree.czf. Nevidím tam žádný důvod, proč by měl pro to dlouhé jméno vrátit NXDOMAIN. Zkuste ten Bind nasměrovat na jiný server – 8.8.8.8, 9.9.9.9, 1.1.1.1 nebo ODVR CZ NICu.

[ktk]

tak konecne zmena!

8.8.8.8 - nic, a  tohle jsem zkousel uz driv, a vyvodil jsem z toho (chybne), ze to nezalezi na tom, koho forwarduju.
9.9.9.9 - nic
ODVR od cznicu - nic
1.1.1.1 - funguje!

Takze decka ted doma muzou na stranky ikea a instalovat veci z applestoru, ale stejne nejsem spokojenej..

Pro ilustraci, takhle vypada tcpdump kdyz ma bind forwardovat 8.8.8.8, zas je tam NXDOMAIN:

Kód: [Vybrat]

12:11:41.711056 IP (tos 0x0, ttl 64, id 60256, offset 0, flags [none], proto UDP (17), length 101)
    ktk.unhfree.czf.52205 > dns.google.domain: 59623+% [1au] A? san.ev11958.ikea.com.edgekey.net. (73)
12:11:41.720580 IP (tos 0x0, ttl 62, id 60206, offset 0, flags [none], proto UDP (17), length 89)
    dns.google.domain > ktk.unhfree.czf.52205: 59623 NXDomain* 0/0/1 (61)
12:11:41.737256 IP (tos 0x0, ttl 64, id 40471, offset 0, flags [DF], proto UDP (17), length 66)
    ktk.unhfree.czf.55136 > ns.unhfree.czf.domain: 14796+ PTR? 8.8.8.8.in-addr.arpa. (38)
12:11:41.742104 IP (tos 0x0, ttl 62, id 60208, offset 0, flags [none], proto UDP (17), length 90)
    ns.unhfree.czf.domain > ktk.unhfree.czf.55136: 14796 1/0/0 8.8.8.8.in-addr.arpa. PTR dns.google. (62)
12:11:41.742276 IP (tos 0x0, ttl 64, id 40472, offset 0, flags [DF], proto UDP (17), length 71)
    ktk.unhfree.czf.58108 > ns.unhfree.czf.domain: 24585+ PTR? 98.250.98.10.in-addr.arpa. (43)
12:11:41.751185 IP (tos 0x0, ttl 62, id 60210, offset 0, flags [none], proto UDP (17), length 100)
    ns.unhfree.czf.domain > ktk.unhfree.czf.58108: 24585 1/0/0 98.250.98.10.in-addr.arpa. PTR ktk.unhfree.czf. (72)
12:11:41.840328 IP (tos 0x0, ttl 64, id 40474, offset 0, flags [DF], proto UDP (17), length 71)
    ktk.unhfree.czf.46650 > ns.unhfree.czf.domain: 57638+ PTR? 66.231.98.10.in-addr.arpa. (43)
12:11:41.856684 IP (tos 0x0, ttl 62, id 60219, offset 0, flags [none], proto UDP (17), length 99)
    ns.unhfree.czf.domain > ktk.unhfree.czf.46650: 57638 1/0/0 66.231.98.10.in-addr.arpa. PTR ns.unhfree.czf. (71)
12:11:42.140678 IP (tos 0x0, ttl 64, id 60354, offset 0, flags [none], proto UDP (17), length 96)
    ktk.unhfree.czf.55800 > dns.google.domain: 12042+% [1au] A? safebrowsing.googleapis.com. (68)
12:11:42.141140 IP (tos 0x0, ttl 64, id 60355, offset 0, flags [none], proto UDP (17), length 96)
    ktk.unhfree.czf.58514 > dns.google.domain: 44212+% [1au] AAAA? safebrowsing.googleapis.com. (68)
12:11:42.145344 IP (tos 0x0, ttl 62, id 60229, offset 0, flags [none], proto UDP (17), length 100)
    dns.google.domain > ktk.unhfree.czf.55800: 12042 1/0/1 safebrowsing.googleapis.com. A 172.217.23.202 (72)
12:11:42.145768 IP (tos 0x0, ttl 64, id 60356, offset 0, flags [none], proto UDP (17), length 83)

A takhle kdyz 1.1.1.1

Kód: [Vybrat]

12:09:46.382301 IP (tos 0x0, ttl 64, id 13591, offset 0, flags [none], proto UDP (17), length 92)
    ktk.unhfree.czf.45525 > one.one.one.one.domain: 34287+% [1au] A? e11958.x.akamaiedge.net. (64)
12:09:46.449508 IP (tos 0x0, ttl 58, id 12577, offset 0, flags [DF], proto UDP (17), length 96)
    one.one.one.one.domain > ktk.unhfree.czf.45525: 34287 1/0/1 e11958.x.akamaiedge.net. A 104.64.121.234 (68)
12:09:46.461112 IP (tos 0x0, ttl 64, id 29067, offset 0, flags [DF], proto UDP (17), length 66)
    ktk.unhfree.czf.57339 > ns.unhfree.czf.domain: 32974+ PTR? 1.1.1.1.in-addr.arpa. (38)
12:09:46.474910 IP (tos 0x0, ttl 62, id 43399, offset 0, flags [none], proto UDP (17), length 95)
    ns.unhfree.czf.domain > ktk.unhfree.czf.57339: 32974 1/0/0 1.1.1.1.in-addr.arpa. PTR one.one.one.one. (67)
12:09:46.475083 IP (tos 0x0, ttl 64, id 29069, offset 0, flags [DF], proto UDP (17), length 71)
    ktk.unhfree.czf.46875 > ns.unhfree.czf.domain: 29508+ PTR? 98.250.98.10.in-addr.arpa. (43)
12:09:46.495870 IP (tos 0x0, ttl 62, id 43400, offset 0, flags [none], proto UDP (17), length 100)
    ns.unhfree.czf.domain > ktk.unhfree.czf.46875: 29508 1/0/0 98.250.98.10.in-addr.arpa. PTR ktk.unhfree.czf. (72)
12:09:46.568335 IP (tos 0x0, ttl 64, id 29071, offset 0, flags [DF], proto UDP (17), length 71)
    ktk.unhfree.czf.60805 > ns.unhfree.czf.domain: 25535+ PTR? 66.231.98.10.in-addr.arpa. (43)
12:09:46.583249 IP (tos 0x0, ttl 62, id 43401, offset 0, flags [none], proto UDP (17), length 99)
    ns.unhfree.czf.domain > ktk.unhfree.czf.60805: 25535 1/0/0 66.231.98.10.in-addr.arpa. PTR ns.unhfree.czf. (71)



[Filip Jirsák]

Zkuste přes uvedené resolvery a také přes resolver vašeho ISP přeložit adresu ze seznamu nepovolených internetových her, třeba thelotter.com. Všechny otevřené resolvery by to měly překládat na jejich opravdové IP adresy, tj. 107.154.132.27 a 107.154.133.27. Váš ISP by to měl přeložit na jinou adresu, kde zobrazí stránku se zákazem přístupu. Takhle si snad vyzkoušíme, zda váš ISP neunáší DNS provoz i pro jiné servery. Je totiž zvláštní, že dostáváte odpověď NXDOMAIN pro existující jméno od různých serverů. Chápal bych, kdyby odpověď vůbec nedorazila, byl problém s fragmentací nebo něčím takovým. To by ukazovalo na problém někde u vás. Ale když dostanete odpověď NXDOMAIN, musí vám tu odpověď někdo poslat. A servery Google i IBM na ten název san.ev11958.ikea.com.edgekey.net normálně odpovídají.

[ktk]

OK, dig pres ISP resolver dostava adresu ze site ISP, na tu kdyz vlezu prohlizecem, presmeruje me to na neco o ministerstvu financi, takze asi podtud OK, musej to delat:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @10.98.231.66 thelotter.com

; <<>> DiG 9.16.1-Ubuntu <<>> @10.98.231.66 thelotter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28317
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;thelotter.com. IN A

;; ANSWER SECTION:
thelotter.com. 86400 IN A 10.98.231.76

;; Query time: 12 msec
;; SERVER: 10.98.231.66#53(10.98.231.66)
;; WHEN: Pá říj 29 15:03:26 CEST 2021
;; MSG SIZE  rcvd: 58

Kdyz se zeptam pres svuj bind (a ten momentalne forwarduje 1.1.1.1), dostanu neco co vypada jako normalni odpoved:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @192.168.2.1 thelotter.com

; <<>> DiG 9.16.1-Ubuntu <<>> @192.168.2.1 thelotter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47747
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 919a65a151684b8301000000617bf24b04b29784cca134c5 (good)
;; QUESTION SECTION:
;thelotter.com. IN A

;; ANSWER SECTION:
thelotter.com. 14400 IN A 107.154.132.27
thelotter.com. 14400 IN A 107.154.133.27

;; Query time: 72 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Pá říj 29 15:08:27 CEST 2021
;; MSG SIZE  rcvd: 102


Kdyz se ale zeptam 8.8.8.8 nebo 9.9.9.9, dostanu zas tu lokalni IP:

Kód: [Vybrat]

ktk@ktk-OptiPlex-7060:~$ dig @8.8.8.8 thelotter.com

; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 thelotter.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10105
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;thelotter.com. IN A

;; ANSWER SECTION:
thelotter.com. 86400 IN A 10.98.231.76

;; Query time: 4 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Pá říj 29 15:09:20 CEST 2021
;; MSG SIZE  rcvd: 58

Chapu to spravne, ze ISP mi teda unasi dns provoz, kdyz se chci ptat googlu nebo quad9?

[Filip Jirsák]

Chapu to spravne, ze ISP mi teda unasi dns provoz, kdyz se chci ptat googlu nebo quad9?

Ano, předpokládám, že váš ISP unáší DNS provoz směrovaný původně na vybrané otevřené DNS resolvery. Je možné, že je dříve nastavoval klientům, a nebo to prostě dělá preventivně. Čtyři jedničky jsou mladšího data, takže je možná do seznamu unášených adres ještě nepřidali.

To vysvětluje, proč se při použití resolveru od Google nebo IBM chová stejně chybně, jako když použijete DNS vašeho ISP. Nicméně to pořád nevysvětluje, proč dostáváte ty chybné odpovědi. Vypadá to ale na chybu DNS resolveru vašeho ISP – tipoval bych to na nějaký problém s validací DNSSEC. Když použijete „obyčejného“ DNS klienta, ten DNSSEC validaci nevyžaduje a vše projde. Když použijete Bind, ten si DNSSEC validaci vyžádá, DNS resolver vašeho ISP něco pokazí a vrátí odpověď, že doména neexistuje.

Nabízelo by se vypnou v Bindu DNSSEC validaci, čemuž bych se ale snažil vyhnout, zejména když váš ISP do DNS provozu zasahuje a kazí ho. Nechal bych tam teď nastavené ty čtyři jedničky, a souběžně s tím to bude chtít řešit s vaším ISP, protože chyba je s největší pravděpodobností u něj.

[ktk]

Oukej, dal to budu resit s ISP a dam vedet, jak to dopadlo.. Kazdopadne dekuji!