dnsmasq-ը մերժում է մասնավոր DNS պատասխանը. rebinding-ի պաշտպանությո՞ւնն է մեղավոր

Ընկերության DNS սերվերը վերադարձնում է սպասվող մասնավոր հասցեն, սակայն տեղական փոխանցող լուծիչով հարցումը դեռ ձախողվում է։ Պատասխանը գոյություն ունի, ինչը բացառում է վերին գոտին և հենց գրառումը։ Մնում է այն քայլը, որտեղ լուծիչը որոշում է՝ վերադարձնե՞լ այդ պատասխանը հաճախորդին։ Եթե այդ լուծիչը dnsmasq է, մերժումը հավանաբար արդեն մատյանում է։

Պատասխան ստանալը և այն վերադարձնելու ընտրությունը երկու տարբեր քայլեր են։

Համեմատեք նույն անունը երկու լուծիչներում

Գրանցեք, թե հավելվածն իրականում որ լուծիչն է օգտագործում և ինչ ճշգրիտ հոսթի անուն է հարցնում։ Այնուհետև համեմատեք վերևից ստացված արդյունքը փոխանցող լուծիչի նույն անվան իրադարձության հետ։ Վերևից պատասխանի բացակայությունը, քեշում պահված բացասական պատասխանը և մատյանում գրանցված մերժումը պահանջում են երեք տարբեր ուղղում։

Ուղղակի ախտորոշիչ հարցման մեջ երևացող հասցեն չի ապացուցում, որ հավելվածն այն ստացել է իր սովորական ուղով։ Երկու հարցումները կարող են դուրս գալ տարբեր լուծիչներից կամ նույն լուծիչից՝ տարբեր կանոններով։ Գրի առեք երկու արդյունքներն էլ նախքան տեսություն կառուցելը, որովհետև հենց այս քայլին է մեկը փոխարինվում մյուսով։ Համեմատությունը ողջ ախտորոշումն է։

Կարդացեք մերժումը, ոչ թե ախտանիշը

dnsmasq-ի stop-dns-rebind ընտրանքը մերժում է վերևից եկած և պայմաններին համապատասխանող մասնավոր հասցեով պատասխանները և դա անելիս գրանցում է դրանք մատյանում։ Այդ պաշտպանությունը գոյություն ունի հիմնավոր պատճառով՝ հանրային անունը, որ հանկարծ լուծվում է մասնավոր հասցեի, դասական rebinding հարձակումն է։ Սակայն այն հատվում է նաև դիտավորյալ մասնավոր ծառայության հետ, և դա ձեր դեպքն է։

Նախքան որևէ բան փոխելը մատյանում փնտրեք մերժումը, որովհետև հաղորդագրությունը նշում է մեխանիզմը։

Եթե ոչ մերժում կա, ոչ էլ վերևից պատասխան, rebinding պաշտպանությունը ձեր խնդիրը չէ, և այն անջատելը կլիներ փոփոխություն, որը ոչինչ չի ուղղում և մեծացնում է խոցելիությունը։ Դա ավելի վատ է, քան սկզբնական խափանումը, որովհետև հեռացնում է վերահսկողություն և թողնում արատը։ Նախ հաստատեք կոնկրետ մատյանի տողը։ Հետո որոշեք։

Սահմանափակեք բացառությունը մեկ դոմենով

Հաստատված դոմենի համար dnsmasq-ի ձեռնարկը առաջարկում է դոմենով սահմանափակված բացառություն, այլ ոչ գլոբալ անջատիչ։

rebind-domain-ok=corp.example

Վերևի դոմենը միայն օրինակ է։ Օգտագործեք այն վարչական դոմենը, որն իսկապես կառավարում եք, և նախքան ընտրանքը կիրառելը հասկացեք դրա համապատասխանության շրջանակը, որովհետև վերջածանցի կանոնը ընդգրկում է ավելին, քան փորձարկված մեկ հոսթը։ Երթուղիչի կարգաբերման գեներատորը կարող է նույն պարամետրը ցուցադրել իր կառավարման միջոցով՝ հում հրահանգի փոխարեն։ Երկու ուղիներն էլ լավ են, եթե ստացված շրջանակը նախատեսվածն է։

rebinding-ի հայտնաբերման բացառությունը ճիշտ մեկ բան է անում՝ թողնում է այդ դոմենի պատասխանները։

Այն չի կարգավորում split-DNS փոխանցիչ, չի դարձնում անհասանելի վերին աղբյուրը հասանելի և չի ստեղծում երթուղի դեպի վերադարձված հասցեն։ Դրանցից յուրաքանչյուրը առանձին պահանջ է՝ իր խափանման նշանով, և յուրաքանչյուրը հաճախորդում ձախողվում է տարբեր կերպ։

Ստուգեք առանց սահմանը հեռացնելու

Կրկին հարցրեք հոսթի անունը փոխանցման ուղով, ապա միացեք ծառայությանը դրա սովորական ինքնության ստուգումներով։ DNS բացառությունը պատճառ չէ ընդունելու անսպասելի վկայական, և երկու խափանումները հեշտ է շփոթել, երբ երկուսն էլ երևում են որպես զննարկիչի սխալ։ Փորձարկեք անունը և ծառայությունը առանձին։ Դրանցից միայն մեկն էր երբևէ DNS խնդիր։

Բացառության պատճառը պահեք կարգաբերման կողքին՝ ամսաթվով և պատասխանատուով։

Նորից ստուգեք այն, երբ մասնավոր ծառայությունը տեղափոխվի կամ դոմենը փոխվի։ Պաշտպանությունը գլոբալ անջատելը կփոխեր անկապ պատասխանների մշակումը և միևնույն է կթողներ երթուղու կամ ծառայության խափանումը, եթե rebinding-ը երբեք պատճառ չի եղել։