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

[ktk]

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.. :/

[Reklama]

[ktk]

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



[vcunat]

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.

[ktk]

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?

[vcunat]

/etc/resolv.conf s tím nemá nic společného, pokud vím.  Cíle forwardování máte v named.conf.options

[Reklama]

[ktk]

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; };
};


[vcunat]

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.

[Marekuss]

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   


[ktk]

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..

[NaRootuJeNeskutecneDebilniRegistracniFormular]

Tohle by mohlo byt limitem na rekurze. Zkus bindu do sekce options pridat max-recursion-queries 100;.

[ktk]

NaRootuJeNeskutecneDebilniRegistracniFormular: Tak limitem rekurze to neni, zkousel jsem nastavovat ruzne hodnoty, (pochopil jsem, ze defautni hodnota je 7) ale bylo to malo platne.

[Dan Ohnesorg]

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)

[rdcz]

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

[ktk]

tak jsem zatim zkusil (bez uspechu, nezmenilo se nic):

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

[NaRootuJeNeskutecneDebilniRegistracniFormular]

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;
       };
};