Puncte:0

Delegare DNS cu BIND și Cloudflare

drapel it

probabil doar o întrebare obișnuită, dar am pierdut ore întregi cu asta de luni de zile. Dacă aveți nevoie de alte jurnale/ieșiri/explicații/etc. doar intreaba :)

Mulțumesc anticipat!

Ceea ce am nevoie

  • Zona local.example.com va fi gestionat de un server local 10.20.0.9
  • Serverele locale (10.20.0.0/24) sunt accesibile numai din interiorul rețelei dar
  • Numele lor de gazdă xxx.local.example.com sunt rezolvabile în întreaga lume de pe internet

Ce am până acum

Folosesc CloudFlare ca furnizor DNS, urmând acest ghid, am configurat următoarele:

  • Înregistrări la CloudFlare:
    ns.example.com A 10.20.0.9 (server DNS local)
    loc.example.com NS ns.example.com (delegare la DNS local)
    
  • Înregistrează fișierul pe serverul meu local DNS (10.20.0.9 folosind bind9)
    loc.example.com. ÎN SOA ns.example.com. hostmaster.example.com. (
        1628517915
        3600
        600
        24 ore
        3600)
    s1.loc.example.com. ÎN A 10.20.0.9
    

Problema mea

CloudFlare nu răspunde la cererea mea de căutare NS pentru loc.example.com cu ns.example.com cum era de așteptat. În schimb, cererea eșuează doar cu „eroare de server” (vezi ultimul jurnal CLI)...

Ieșire CLI

  • dig ns.example.com

    ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> ns.example.com
    ;; opțiuni globale: +cmd
    ;; Am răspuns:
    ;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 10036
    ;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1
    
    ;; PSEUDOSECȚIE OPT:
    ; EDNS: versiunea: 0, steaguri:; udp: 1232
    ;; SECȚIUNEA DE ÎNTREBĂRI:
    ;ns.example.com. ÎN A
    
    ;; SECȚIUNEA RĂSPUNSURI:
    ns.example.com. 300 ÎN A 10.20.0.9
    
    ;; Timp de interogare: 111 ms
    ;; SERVER: 1.1.1.1#53(1.1.1.1)
    ;; CÂND: Luni, 9 august, 16:42:06 CEST 2021
    ;; MSG SIZE rcvd: 66
    

    Deci serverul de nume se rezolvă la IP-ul nostru local, frumos!

  • dig @10.20.0.9 NS loc.example.com

    ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @10.20.0.9 NS loc.example.com
    ; (1 server găsit)
    ;; opțiuni globale: +cmd
    ;; Am răspuns:
    ;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 47653
    ;; steaguri: qr aa rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 0, SUPLIMENTARE: 1
    
    ;; PSEUDOSECȚIE OPT:
    ; EDNS: versiunea: 0, steaguri:; udp: 4096
    ; COOKIE: 7fa7e218d1c20f1e113b236e61113fb96c1b101d374cbde7 (bine)
    ;; SECȚIUNEA DE ÎNTREBĂRI:
    ;loc.example.com. ÎN NS
    
    ;; SECȚIUNEA RĂSPUNSURI:
    loc.example.com. 3600 ÎN NS ns.example.com.
    
    ;; Timp de interogare: 1 ms
    ;; SERVER: 10.20.0.9#53(10.20.0.9)
    ;; CÂND: Luni, 9 august, 16:46:17 CEST 2021
    ;; MSG SIZE rcvd: 96
    

    Serverul nostru DNS local știe că este responsabil pentru subdomeniul

  • dig @10.20.0.9 s1.loc.example.com

    ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @10.20.0.9 s1.loc.example.com
    ; (1 server găsit)
    ;; opțiuni globale: +cmd
    ;; Am răspuns:
    ;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 38039
    ;; steaguri: qr aa rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 1, SUPLIMENTARE: 1
    
    ;; PSEUDOSECȚIE OPT:
    ; EDNS: versiunea: 0, steaguri:; udp: 4096
    ; COOKIE: 7790b2d359140e5f04be8596611140927c7321fefc1fbbe9 (bine)
    ;; SECȚIUNEA DE ÎNTREBĂRI:
    ;s1.loc.example.com. ÎN A
    
    ;; SECȚIUNEA RĂSPUNSURI:
    s1.loc.example.com. 3600 ÎN A 10.20.0.1
    
    ;; SECȚIUNEA AUTORITATE:
    loc.example.com. 3600 ÎN NS ns.example.com.
    
    ;; Timp de interogare: 1 ms
    ;; SERVER: 10.20.0.9#53(10.20.0.9)
    ;; CÂND: Luni, 9 august, 16:49:54 CEST 2021
    ;; MSG SIZE rcvd: 119
    

    Deci, DNS-ul local poate rezolva gazdele noastre locale

  • dig @1.1.1.1 NS loc.example.com

    ; <<>> DiG 9.11.5-P4-5.1+deb10u5-Debian <<>> @1.1.1.1 NS loc.example.com
    ; (1 server găsit)
    ;; opțiuni globale: +cmd
    ;; Am răspuns:
    ;; ->>HEADER<<- opcode: QUERY, stare: SERVFAIL, id: 33748
    ;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 0, AUTORITATE: 0, SUPLIMENTARE: 1
    
    ;; PSEUDOSECȚIE OPT:
    ; EDNS: versiunea: 0, steaguri:; udp: 1232
    ; OPT=15: 00 16 (""..")
    ;; SECȚIUNEA DE ÎNTREBĂRI:
    ;loc.example.com. ÎN NS
    
    ;; Timp de interogare: 12 ms
    ;; SERVER: 1.1.1.1#53(1.1.1.1)
    ;; CÂND: Luni, 9 august, 16:51:45 CEST 2021
    ;; MSG SIZE rcvd: 57
    

    Aici este problema: CloudFlare NU răspunde la cererea noastră de înregistrare NS. De ce :o?

drapel cn
Este o problemă de conectivitate? Există vreo modalitate ca „1.1.1.1” să ajungă la serverul dvs. de nume? (Firewall?)
drapel fr
Nu puteți avea nume care pot fi rezolvate public în cazul în care serverele de nume responsabile pentru aceste nume sunt în intervalele de adrese RFC1918.
drapel it
@Tomek, dar cum se ocupă cei mari de aceste sarcini? Adică, mi-aș putea împinge clienții VPN pe serverul DNS local, dar acest lucru va suprascrie setările lor DNS și pentru toate celelalte domenii...
drapel fr
Exact asta face VPN-ul angajatorului meu atunci când îl folosesc. În plus, înlocuiește ruta implicită, care oricum invalidează orice alte servere de nume.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.