Fórum Root.cz

Hlavní témata => Server => Téma založeno: ktk 10. 10. 2021, 13:47:05

Název: BIND nepřekládá některé domény
Přispěvatel: ktk 10. 10. 2021, 13:47:05
Ahoj, zacal se mi asi tak pred mesicem (nekdy behem zari, mozna driv) objevovat zajimavy problem s DNS v siti.

Popisu situaci:

na pude mam pocitac s debianem, co ma dve sitovky, jednou je pripichnutej k ISP, tam dostava IP adresu z rozsahu 10.x.x.x, druha je do domaci site, kde je rozsah 192.168.2.x.

na tomhle pocitaci (rikam mu gw jako gateway) bezi NAT s maskaradou, jednoduchy nftables firewall, dhcpd pro lokalni sit, a bind tez pro lokalni sit. Asi nic neobvykleho. Ten bind je tam proto, aby nejaky domeny .gw koncily na tomhle pocitaci, protoze tam mam nejaky sluzby, ktery chci takhle z lokalni site videt. Jinak chci, aby dns fungovalo to od ISP. DHCPd samozrejme jako dns server propaguje 192.168.2.1, coz je IP ty gw.

Od ISP ten pocitact dostava DNS servery, ktere zda se funguji v poradku:

Kód: [Vybrat]
root@router:/etc/bind# cat /etc/resolv.conf
domain unhfree.czf
search unhfree.czf
nameserver 10.98.231.66
nameserver 10.98.0.250
root@router:/etc/bind# dig www.ikea.com

; <<>> DiG 9.16.15-Debian <<>> www.ikea.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13450
;; 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. 66303 IN CNAME san.ev11958.ikea.com.edgekey.net.
san.ev11958.ikea.com.edgekey.net. 1503 IN CNAME e11958.x.akamaiedge.net.
e11958.x.akamaiedge.net. 20 IN A 104.64.121.234

;; Query time: 8 msec
;; SERVER: 10.98.231.66#53(10.98.231.66)
;; WHEN: Ne říj 10 13:03:36 CEST 2021
;; MSG SIZE  rcvd: 137
Jak je videt. IP dostanu, i na ten web se z linksu podivam.

Problem je ale na vsech pocitacich, ktery jsou v lokalni siti, a maji jako dns server tu gw.

hle:

Kdyz se zeptam z pocitace v siti, dostanu prd. (tohle je ubuntu, ktery ma asi nejakou mezivrstvu, bo ma resolf.conf tohle - ale treba androidi telefony maji stejny problem.

Kód: [Vybrat]
nameserver 127.0.0.53
options edns0 trust-ad
search kktnk.router


Kód: [Vybrat]
; <<>> DiG 9.16.1-Ubuntu <<>> www.ikea.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9152
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

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

;; Query time: 32 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Ne říj 10 13:07:49 CEST 2021
;; MSG SIZE  rcvd: 41

Kdyz se zeptam pres gw, je to o chlup lepsi dostanu cname, ale to neni moc platny:
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: 41534
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

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

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

;; Query time: 12 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Ne říj 10 13:08:06 CEST 2021
;; MSG SIZE  rcvd: 115

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

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: d80f9182ab1f874e010000006162c9dc090adad20ae28151 (good)
;; QUESTION SECTION:
;san.ev11958.ikea.com.edgekey.net. IN A

;; Query time: 8 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Ne říj 10 13:09:16 CEST 2021
;; MSG SIZE  rcvd: 89

Teprve kdyz se zeptam pres dns od ISP (nebo treba googlu), dostanu odpoved.

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: 33221
;; 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. 65914 IN CNAME san.ev11958.ikea.com.edgekey.net.
san.ev11958.ikea.com.edgekey.net. 1114 IN CNAME e11958.x.akamaiedge.net.
e11958.x.akamaiedge.net. 20 IN A 104.64.121.234

;; Query time: 7 msec
;; SERVER: 10.98.231.66#53(10.98.231.66)
;; WHEN: Ne říj 10 13:10:05 CEST 2021
;; MSG SIZE  rcvd: 137

Dela to vic webu, ne jen ta ikea, na vsech pocitacich v siti. A spolecny znak, ktery jsem zatim vypozoroval, ze jsou vesmes CNAME na jinou domenu s .net TLD. Ale to muze bejt falesna stopa. Prikladam i konfiguraky toho bindu, pokud to necemu pomuze.

Neni tu nekdo znalejsi nez ja, kdo by se kouknul a videl? Ja vidim prd.. :/
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 10. 10. 2021, 15:35:10
Tak stopa s .net TLD je patrne licha, kdyz zkusim dig www.amazon.com, je to podobna situace, ale IP dostanu:

Kód: [Vybrat]
ktk@ktk-OptiPlex-7060:~$ dig www.amazon.com

; <<>> DiG 9.16.1-Ubuntu <<>> www.amazon.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17906
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
www.amazon.com. 95 IN CNAME tp.47cf2c8c9-frontier.amazon.com.
tp.47cf2c8c9-frontier.amazon.com. 49 IN CNAME www-amazon-com.customer.fastly.net.
www-amazon-com.customer.fastly.net. 236 IN A 162.219.225.118

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Ne říj 10 15:33:11 CEST 2021
;; MSG SIZE  rcvd: 143

Název: Re:BIND nepřekládá některé domény
Přispěvatel: vcunat 10. 10. 2021, 17:06:28
Celkově bych čekal problém v nějakém detailu u ISP resolveru... asi to poznáte nejsnáze (dočasnou) výměnou jejich adres za 9.9.9.9 nebo jiný relativně spolehlivý resolver.  Ale 100% jistý se asi nedá být dokud člověk nechytí dané problematické packety.

- - -

QNAME minimalizace někdy odkrývá další chyby v implementacích - nejde jen o odpověď na finální jméno, ale třeba i NXDOMAIN na mezilehlém jméně "dokazuje" neexistenci jména samotného.  Běžně podobné problémy bývají chybami CDN, i když Akamai bylo myslím poslední dobou už v tomhle spolehlivé (a dané jméno vypadá z mé stany OK), takže spíš ten ISP anebo pokud máte bug v dané staré verzi BINDu.

Třeba ten systemd-resolved (127.0.0.53#53) vypadá na případ takového problému v implementaci.  Zřejmě vám vrací NXDOMAIN i přesto, že BIND ze kterého čerpá vrací CNAME na jiné jméno které má NXDOMAIN.  Rozdíl je například v tom, že jedno implikuje neexistenci čehokoliv v podstromu www.ikea.com a druhé ne.

> stopa s .net

Spíše než dle TLD bych čekal uniformní chování pro danou CDN.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 10. 10. 2021, 17:50:13
Obavam se, ze na me hovorite krapet spanelsky, natolik kovanej v dns nejsem.. :/

Ale na systemd-resolved v ubuntu bych to nehazel, dela to i na androidich i jablecnych mobilech, co jsou v siti.

Zmenil jsem /etc/resolv.conf na gw, aby tam byl jen 8.8.8.8:

Kód: [Vybrat]
ktk@router:~$ cat /etc/resolv.conf
#domain unhfree.czf
#search unhfree.czf
#nameserver 10.98.231.66
#nameserver 10.98.0.250
nameserver 8.8.8.8

A efekt to zadny nemelo. Takze to znaci, ze problem je v mym bindu? Opravdu to vypada ne nejaky vetsi cdn, nejedou veci typu aliexpress.com, microsoft.com, ... Je to bind ze stabilniho debianu - bullseye, tak (mozna chybne) predpokladam, ze bug s takovym dosahem by byl davno vyresenej.

V zasade by mi nevadilo dat tam misto bindu cokoliv, co je v debianu a umi to co potrebuju (viz vyse). Je nejaka alternativa? je treba unbound pro me?
Název: Re:BIND nepřekládá některé domény
Přispěvatel: vcunat 10. 10. 2021, 18:04:11
/etc/resolv.conf s tím nemá nic společného, pokud vím.  Cíle forwardování máte v named.conf.options
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 10. 10. 2021, 18:10:48
pravda. upravil jsem to tam, restartoval bind, ale vsechno pri starem.

Kód: [Vybrat]
root@router:/home/ktk# cat /etc/bind/named.conf.options
options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders. 
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

forwarders {
// 10.98.231.66;
// 10.98.0.250;
8.8.8.8;
};

forward only;

allow-recursion { any; };
allow-query { any; };
allow-query-cache { any; };

//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys.  See https://www.isc.org/bind-keys
//========================================================================
dnssec-enable yes;
dnssec-validation auto;
//dnssec-validation no;

auth-nxdomain no;    # conform to RFC1035
listen-on-v6 { any; };

listen-on { 192.168.2.1; };
};
Název: Re:BIND nepřekládá některé domény
Přispěvatel: vcunat 10. 10. 2021, 18:24:41
No tak nevím, možná by to bylo na dlouhé zkoumání, třeba někdo jiný bude mít lepší nápad (v bindu konkrétně se moc nevyznám).

Buster nemá nijak moc starou verzi a snad by tam takovou chybu někdo řešil (pokud nejde třeba o lokální anomálii v CDN), takže je i možnost, že ISP krade veškerý provoz na portu 53.  O tom jsem občas slyšel.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Marekuss 11. 10. 2021, 10:16:25
Riesil som podobnu vec, len rozdiel BIND -> UNBOUND. Linux(nftables) -> BSD(pf), ale +- situacia je rovnaka.

Zacal by som pozretim logov v BIND a este lepsie, traffic cez "tcpdump", uvidis tam vsetko relevantne
Dalej, v ubuntu mozes nastavit na "tvrdo" resolve DNS
Kód: [Vybrat]
# /etc/systemd/resolved.conf
[Resolve]
DNS=192.168.1.1
FallbackDNS=192.168.1.1 1.1.1.1 8.8.8.8

a taktiez skontrolovat ci mas dobre nakonfigurovane DoT (DNS over TLS), android to standardne vyuziva
ku prikladu, moj unbound.conf vyzera nejako takto:
Kód: [Vybrat]
## unbound.conf
#
server:
   
    chroot: ""

    interface: 0.0.0.0@53
    port: 53

    interface: 0.0.0.0@853
    ssl-port: 853                                     
   
  # log verbosity
    verbosity: 1
    log-queries: yes
    logfile: /var/log/unbound.log

  # Enable IPv4, "yes" or "no".
    do-ip4: yes
    do-ip6: no
    do-udp: yes
    do-tcp: yes

  # Access control
    access-control: 127.0.0.0/8 allow
    access-control: 192.168.0.0/16 allow
    access-control: 172.16.0.0/16 allow

    hide-identity: yes
    hide-version: yes
    harden-glue: yes
    harden-dnssec-stripped: yes

    unwanted-reply-threshold: 10000
    do-not-query-localhost: no
    auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"
    val-clean-additional: yes

    private-address: 192.168.0.0/16
    private-address: 172.16.0.0/12

    private-domain: "server.lan"

  # locally served zones can be configured for the machines on the LAN.
    local-zone: "server.lan." static

    local-data: "smb.server.lan.      IN A 192.168.2.2"
    local-data: "ftp.server.lan.      IN A 192.168.2.3"

    local-data-ptr: "192.168.2.2  smb.server.lan"
    local-data-ptr: "192.168.2.3  ftp.server.lan"

  forward-zone:
     name: "server.lan"
     forward-addr: 127.0.0.1       # Internal or private DNS

  # Use the following forward-zone to forward all queries to Google DNS,
  # OpenDNS.com or your local ISP's dns servers for example. To test resolution
  # speeds use "drill calomel.org @8.8.8.8" and look for the "Query time:" in
  # milliseconds.
  #
  forward-zone:
   name: "."
   
   forward-addr: 1.1.1.1@53#one.one.one.one
   forward-addr: 8.8.8.8@53#dns.google
   forward-addr: 9.9.9.9@53#dns.quad9.net
   forward-addr: 1.0.0.1@53#one.one.one.one
   forward-addr: 8.8.4.4@53#dns.google
   forward-addr: 149.112.112.112@53#dns.quad9.net
   
   forward-addr: 1.1.1.1@853#cloudflare-dns.com
   forward-addr: 9.9.9.9@853#dns.quad9.net   

Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 12. 10. 2021, 09:45:10
No, podle mych moznosti mi vychazi jako dalsi krok zkusit vymenit ten bind za unbound.

Uvidime, zda to zabere. Zatim vam vsem diky za rady a prispevky..
Název: Re:BIND nepřekládá některé domény
Přispěvatel: NaRootuJeNeskutecneDebilniRegistracniFormular 12. 10. 2021, 15:47:24
Tohle by mohlo byt limitem na rekurze. Zkus bindu do sekce options pridat max-recursion-queries 100;.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 14. 10. 2021, 09:21:24
NaRootuJeNeskutecneDebilniRegistracniFormular: Tak limitem rekurze to neni, zkousel jsem nastavovat ruzne hodnoty, (pochopil jsem, ze defautni hodnota je 7) ale bylo to malo platne.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Dan Ohnesorg 14. 10. 2021, 15:07:24
Hledal bych chybu v necem z:

spatne MTU, firewall blokuje PMTU discovery

nepovoleny TCP port 53 (ano DNS je primarne UDP, ale "velke" odpovedi si muze vymenovat pres TCP)

spatna konfigurace IPv6 (router vypada ze ma IPv6 adresu, ale ta neni z internetu dosazitelna)

problem s NATem providera (prilis mnoho DNS dotazu z jedne IP adresy)
Název: Re:BIND nepřekládá některé domény
Přispěvatel: rdcz 15. 10. 2021, 12:19:36
S velkou pravděpodobností to dělá síťová karta - hw checksumming.
Zkuste (název interfejsu doplňte vlastní):
Kód: [Vybrat]
# ethtool -k enp2s0 |grep checksummingPokud tam uvidíte
rx-checksumming: on
tx-checksumming: on
tak to zkuste vypnout příkazem
Kód: [Vybrat]
# ethtool -K enp2s0 tx off rx offa mělo by to začít fungovat.

Pokud máte víc síťovek, nastavte pro každou zvlášť.
Tato změna není perzistentní, takže po rebootu je nutné to nastavit znovu.
Pokud požíváte NetworkManager lze za zařídit příkazem:
Kód: [Vybrat]
# nmcli con modify enp2s0 ethtool.feature-rx off ethtool.feature-tx off
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 16. 10. 2021, 10:50:21
tak jsem zatim zkusil (bez uspechu, nezmenilo se nic):

# otevrit port 53 - predpokladam na rozhrani do internetu.
# vypnout checksumming

Název: Re:BIND nepřekládá některé domény
Přispěvatel: NaRootuJeNeskutecneDebilniRegistracniFormular 18. 10. 2021, 09:55:47
A co prestat hadat a zapnout debug?
Kód: [Vybrat]
logging {
       channel tmp_resolver_log {
               file "/tmp/resolver.log" versions 3 size 1g;
               severity debug 3;
               print-time yes;
       };
       category resolver {
               tmp_resolver_log;
       };

       channel tmp_queries_log {
               file "/tmp/queries.log" versions 3 size 1g;
               severity debug 3;
               print-time yes;
       };
       category queries {
               tmp_queries_log;
       };
};

Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 28. 10. 2021, 12:49:37
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?
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Filip Jirsák 28. 10. 2021, 13:02:10
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á.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 28. 10. 2021, 13:44:37
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
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Filip Jirsák 28. 10. 2021, 14:06:48
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ěď.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 28. 10. 2021, 14:29:29
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.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Filip Jirsák 28. 10. 2021, 14:33:03
Tohle je ale jiná komunikace. Zeptejte se na ten název san.ev11958.ikea.com.edgekey.net, na který se ptá Bind.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 28. 10. 2021, 14:44:11
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)
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Filip Jirsák 28. 10. 2021, 15:03:57
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.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 29. 10. 2021, 12:17:42
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)

Název: Re:BIND nepřekládá některé domény
Přispěvatel: Filip Jirsák 29. 10. 2021, 13:21:09
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í.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 29. 10. 2021, 15:14:55
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?
Název: Re:BIND nepřekládá některé domény
Přispěvatel: Filip Jirsák 29. 10. 2021, 17:21:53
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.
Název: Re:BIND nepřekládá některé domény
Přispěvatel: ktk 29. 10. 2021, 18:25:30
Oukej, dal to budu resit s ISP a dam vedet, jak to dopadlo.. Kazdopadne dekuji!