{"id":33717,"date":"2019-10-31T21:54:20","date_gmt":"2019-10-31T18:54:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/delegirovanie-obratnoj-zony-podseti-menee-24-v-bind-kak-eto-rabotaet\/"},"modified":"2019-10-31T21:54:20","modified_gmt":"2019-10-31T18:54:20","slug":"delegirovanie-obratnoj-zony-podseti-menee-24-v-bind-kak-eto-rabotaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/delegirovanie-obratnoj-zony-podseti-menee-24-v-bind-kak-eto-rabotaet","title":{"rendered":"Delegazione della zona inversa della sottorete inferiore a \/24 in BIND. Come funziona","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Una volta mi \u00e8 stato chiesto di concedere a uno dei clienti il diritto di modificare i record PTR della subnet \/28 a lui assegnata. Non ho automazione per modificare le impostazioni BIND da remoto. Cos\u00ec ho deciso di seguire un'altra strada: delegare al cliente una parte della zona PTR della subnet \/24.<\/p>\n

Sembrerebbe che sia un'impresa semplice. Basta scrivere correttamente la subnet e indirizzarla al NS desiderato, come si fa con un sottodominio. Ma no. Non \u00e8 tutto cos\u00ec semplice (anche se in realt\u00e0 \u00e8 piuttosto primitivo, ma l'intuizione non aiuter\u00e0), ed \u00e8 per questo che scrivo questo articolo.<\/p>\n

Chi desidera approfondire pu\u00f2 leggere RFC<\/a><\/noindex>
\nPer chi cerca una soluzione pronta, benvenuti sotto il post.
\n<\/a><\/noindex>
\nPer non trattenere coloro che amano il metodo copia-incolla, inizier\u00f2 con la parte pratica e dopo di essa ci sar\u00e0 quella teorica.<\/p>\n

1. Pratica. Delega la zona \/28<\/b><\/p>\n

Supponiamo di avere una subnet 7.8.9.0\/24<\/b>. Dobbiamo delegare la subnet 7.8.9.240\/28<\/b> al client DNS 7.8.7.8<\/b> (ns1.client.domain<\/b>).<\/p>\n

Sul DNS del provider, \u00e8 necessario trovare il file che descrive la zona inversa di questa subnet. Supponiamo sia 9.8.7.in-addr.arpa<\/b>.
\nCommentiamo i record da 240 a 255, se presenti. E aggiungiamo alla fine del file quanto segue:<\/p>\n

255-240  IN  NS      7.8.7.8\n$GENERATE 240-255 $ CNAME $.255-240<\/code><\/pre>\n
\nnon dimentichiamo di aumentare il numero di versione delle zone seriali e procediamo <\/p>\n
rndc reload<\/code><\/pre>\n
\nLa parte del provider \u00e8 terminata. Passiamo al DNS client.<\/p>\n
Iniziamo creando un file \/etc\/bind\/master\/255-240.9.8.7.in-addr.arpa<\/b> con il seguente contenuto:<\/p>\n
$ORIGIN 255-240.9.8.7.in-addr.arpa.\n$TTL 1W\n@                       1D IN SOA       ns1.client.domain. root.client.domain. (\n                        2008152607      ; seriale\n                        3H              ; refresh\n                        15M             ; retry\n                        1W              ; scadenza\n                        1D )            ; minimo\n@                       IN NS        ns1.client.domain.\n@                       IN NS        ns2.client.domain.\n241                     IN PTR          test.client.domain.\n242                     IN PTR          test2.client.domain.\n245                     IN PTR          test5.client.domain.\n<\/code><\/pre>\n
\nE in named.conf<\/b> aggiungiamo la descrizione del nostro nuovo file:<\/p>\n
zone \"255-240.9.8.7.in-addr.arpa.\" IN {\n        type master;\n        file \"master\/255-240.9.8.7.in-addr.arpa\";\n};<\/code><\/pre>\n
\nPoi riavviamo il processo bind.<\/p>\n
\/etc\/init.d\/named restart<\/code><\/pre>\n
\nTutto. Ora possiamo controllare.<\/p>\n
#>  host 7.8.9.245 \n245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.\n245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.<\/code><\/pre>\n
\nNota che vengono restituiti non solo i record PTR ma anche i CNAME. \u00c8 tutto normale. Se sei curioso sul perch\u00e9, benvenuto al capitolo successivo.<\/p>\n
2. Teoria. Come funziona.<\/b><\/p>\n
\u00c8 difficile configurare e debug un black box. \u00c8 molto pi\u00f9 semplice se capisci cosa succede all'interno.<\/p>\n
Quando deleghiamo un sottodominio in un dominio dominio<\/b>, scriviamo qualcosa del genere:<\/p>\n
client.domain.\tNS\tns1.client.domain.\nns1.client.domain.\tA\t7.8.7.8<\/code><\/pre>\n
\nDiciamo a tutti coloro che chiedono che non siamo responsabili per questa zona e chi \u00e8 responsabile. E tutte le richieste a client.domain<\/b> vengono reindirizzate a 7.8.7.8. Durante il controllo vediamo la seguente situazione (sottintendendo cosa c'\u00e8 dal cliente; non \u00e8 importante):<\/p>\n
# host test.client.domain\ntest.client.domain has address 7.8.9.241<\/code><\/pre>\n
\nCio\u00e8, ci \u00e8 stato comunicato che esiste un record A e il suo ip 7.8.9.241. Nessuna informazione aggiuntiva.<\/p>\n
E come si pu\u00f2 fare lo stesso con una sottorete?<\/b><\/p>\n
Poich\u00e9 il nostro server DNS \u00e8 registrato in RIPE, quando viene effettuata una richiesta PTR per l'ip dalla nostra rete, la prima richiesta sar\u00e0 comunque verso di noi. La logica \u00e8 la stessa che con i domini. Ma come scrivere la sottorete nel file di zona?<\/p>\n
Proviamo a scrivere in questo modo:<\/p>\n
255-240  IN  NS      7.8.7.8<\/code><\/pre>\n
\nE... il miracolo non \u00e8 avvenuto. Non riceviamo alcun reindirizzamento della richiesta. Il punto \u00e8 che bind non \u00e8 affatto a conoscenza che queste voci nel file di zona inversa sono indirizzi IP e, a maggior ragione, non comprende la voce di intervallo. Per lui \u00e8 semplicemente un sottodominio simbolico. Quindi, per bind non ci sar\u00e0 differenza tra «255-240<\/b>» e «oursuperclient<\/b>«. E la richiesta affinch\u00e9 venga indirizzata correttamente, l'indirizzo nella richiesta deve apparire in questo modo: 241.255-240.9.8.7.in-addr.arpa<\/b>. O in questo modo, se usiamo un sottodominio simbolico: 241.oursuperclient.9.8.7.in-addr.arpa<\/b>. Questo \u00e8 diverso dal normale: 241.9.8.7.in-addr.arpa<\/b>.<\/p>\n
\u00c8 complicato effettuare una richiesta del genere manualmente. E se ci riesci, non \u00e8 chiaro come applicarlo nella vita reale. Infatti, la richiesta 7.8.9.241<\/b> continua a rispondere il DNS del provider, non quello del cliente.<\/p>\n
E qui entra in gioco CNAME<\/b>.<\/p>\n
Dallato del provider, \u00e8 necessario creare un alias per tutti gli indirizzi IP della sottorete in un formato che reindirizzi la richiesta al DNS del cliente.<\/p>\n
255-240  IN  NS      ns1.client.domain.\n241     IN  CNAME   241.255-240\n242     IN  CNAME   242.255-240\ne cos\u00ec via.\n<\/code><\/pre>\n
\nQuesto \u00e8 per i lavoratori =). <\/p>\n
E per i pi\u00f9 pigri, \u00e8 pi\u00f9 adatta la costruzione seguente:<\/p>\n
255-240  IN  NS      ns1.client.domain.\n$GENERATE 240-255 $ CNAME $.255-240<\/code><\/pre>\n
\nOra la richiesta di informazioni all'indirizzo 7.8.9.241<\/b> di 241.9.8.7.in-addr.arpa<\/b> sul server DNS del provider verr\u00e0 trasformata in 241.255-240.9.8.7.in-addr.arpa<\/b> e si diriger\u00e0 verso il DNS del cliente. <\/p>\n
Dal lato del cliente, sar\u00e0 necessario gestire tali richieste. Pertanto, creiamo la zona 255-240.9.8.7.in-addr.arpa<\/b>. In essa possiamo in linea di principio collocare record inversi per qualsiasi IP dell'intera sottorete \/24, ma ci chiederanno solo quelli a cui il provider ci reindirizza, quindi non ci si pu\u00f2 divertire =).
\nPer illustrare, riporto ancora un esempio del contenuto del file di zona inversa da parte del cliente:<\/p>\n
$ORIGIN 255-240.9.8.7.in-addr.arpa.\n$TTL 1W\n@                       1D IN SOA       ns1.client.domain. root.client.domain. (\n                        2008152607      ; seriale\n                        3H              ; refresh\n                        15M             ; retry\n                        1W              ; scadenza\n                        1D )            ; minimo\n@                       IN NS        ns1.client.domain.\n@                       IN NS        ns2.client.domain.\n241                     IN PTR          test.client.domain.\n242                     IN PTR          test2.client.domain.\n245                     IN PTR          test5.client.domain.\n<\/code><\/pre>\n
\nQuesto \u00e8 il motivo per cui, da parte del fornitore, utilizziamo CNAME, e quindi riceviamo in risposta una richiesta di dati per indirizzo IP<\/a> due record, e non uno solo.<\/p>\n
#>  host 7.8.9.245 \n245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.\n245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.<\/code><\/pre>\n
\nE non dimenticate di configurare correttamente le ACL. Perch\u00e9 non ha senso prendere la zona PTR e non rispondere a nessuno dall'esterno =).<\/b><\/i>
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412\u0441\u0442\u0430\u043b\u0430 \u043e\u0434\u043d\u0430\u0436\u0434\u044b \u043f\u0435\u0440\u0435\u0434\u043e \u043c\u043d\u043e\u0439 \u0437\u0430\u0434\u0430\u0447\u0430, \u043e\u0442\u0434\u0430\u0442\u044c \u043e\u0434\u043d\u043e\u043c\u0443 \u0438\u0437 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043f\u0440\u0430\u0432\u043e \u043d\u0430 \u0440\u0435\u0434\u0430\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 PTR-\u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u043e\u0442\u0434\u0430\u043d\u043d\u043e\u0439 \u0435\u043c\u0443 \u043f\u043e\u0434\u0441\u0435\u0442\u0438 \/28. \u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u0440\u0435\u0434\u0430\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430\u0441\u0442\u0440\u043e\u0435\u043a BIND \u0438\u0437\u0432\u043d\u0435 \u0443 \u043c\u0435\u043d\u044f \u043d\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u0440\u0435\u0448\u0438\u043b \u043f\u043e\u0439\u0442\u0438 \u0434\u0440\u0443\u0433\u0438\u043c \u043f\u0443\u0442\u0435\u043c \u2014 \u0434\u0435\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043a\u043b\u0438\u0435\u043d\u0442\u0443 \u043a\u0443\u0441\u043e\u043a PTR-\u0437\u043e\u043d\u044b \u043f\u043e\u0434\u0441\u0435\u0442\u0438 \/24. \u041a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0431\u044b \u2014 \u0447\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043f\u0440\u043e\u0449\u0435? \u041f\u0440\u043e\u0441\u0442\u043e \u043d\u0443\u0436\u043d\u044b\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043f\u0440\u043e\u043f\u0438\u0441\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434\u0441\u0435\u0442\u044c \u0438 \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u043c \u043d\u0430 \u043d\u0443\u0436\u043d\u044b\u0439 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33717","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Delegazione della zona inversa di una sottorete inferiore a \/24 in BIND. Come funziona | ProHoster","description":"Un giorno mi sono trovato di fronte alla necessit\u00e0 di dare a uno dei miei clienti il diritto di modificare i record PTR della sottorete \/28 che gli era stata assegnata. Non ho alcuna automazione per modificare le impostazioni di BIND da remoto. Quindi ho deciso di andare per un'altra strada: delegare al cliente un pezzo della zona PTR della sottorete \/24. Sembrerebbe \u2014 cosa pu\u00f2 essere pi\u00f9 semplice? Basta definire la sottorete in modo appropriato e indirizzarla verso il","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/delegirovanie-obratnoj-zony-podseti-menee-24-v-bind-kak-eto-rabotaet","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u0435\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0437\u043e\u043d\u044b \u043f\u043e\u0434\u0441\u0435\u0442\u0438 \u043c\u0435\u043d\u0435\u0435 \/24 \u0432 BIND. \u041a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 | ProHoster","og:description":"\u0412\u0441\u0442\u0430\u043b\u0430 \u043e\u0434\u043d\u0430\u0436\u0434\u044b \u043f\u0435\u0440\u0435\u0434\u043e \u043c\u043d\u043e\u0439 \u0437\u0430\u0434\u0430\u0447\u0430, \u043e\u0442\u0434\u0430\u0442\u044c \u043e\u0434\u043d\u043e\u043c\u0443 \u0438\u0437 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043f\u0440\u0430\u0432\u043e \u043d\u0430 \u0440\u0435\u0434\u0430\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 PTR-\u0437\u0430\u043f\u0438\u0441\u0435\u0439 \u043e\u0442\u0434\u0430\u043d\u043d\u043e\u0439 \u0435\u043c\u0443 \u043f\u043e\u0434\u0441\u0435\u0442\u0438 \/28. \u0410\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0437\u0430\u0446\u0438\u0438 \u0434\u043b\u044f \u0440\u0435\u0434\u0430\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430\u0441\u0442\u0440\u043e\u0435\u043a BIND \u0438\u0437\u0432\u043d\u0435 \u0443 \u043c\u0435\u043d\u044f \u043d\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u0440\u0435\u0448\u0438\u043b \u043f\u043e\u0439\u0442\u0438 \u0434\u0440\u0443\u0433\u0438\u043c \u043f\u0443\u0442\u0435\u043c \u2014 \u0434\u0435\u043b\u0435\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043a\u043b\u0438\u0435\u043d\u0442\u0443 \u043a\u0443\u0441\u043e\u043a PTR-\u0437\u043e\u043d\u044b \u043f\u043e\u0434\u0441\u0435\u0442\u0438 \/24. \u041a\u0430\u0437\u0430\u043b\u043e\u0441\u044c \u0431\u044b \u2014 \u0447\u0442\u043e \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043f\u0440\u043e\u0449\u0435? \u041f\u0440\u043e\u0441\u0442\u043e \u043d\u0443\u0436\u043d\u044b\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043f\u0440\u043e\u043f\u0438\u0441\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434\u0441\u0435\u0442\u044c \u0438 \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u043c \u043d\u0430 \u043d\u0443\u0436\u043d\u044b\u0439","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/delegirovanie-obratnoj-zony-podseti-menee-24-v-bind-kak-eto-rabotaet","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:54:20+00:00","article:modified_time":"2019-10-31T18:54:20+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33717","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-08 20:27:18","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:35:31","updated":"2026-02-08 20:27:18","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33717","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33717"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33717\/revisions"}],"predecessor-version":[{"id":157777,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33717\/revisions\/157777"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33717"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33717"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33717"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}