Ներքին լուծիչը առաջին, իսկ հանրայինը երկրորդ տեղում դնելը Squid-ին չի ասում, թե որ անունները որ անվանատարածքին են պատկանում։

Squid 6-ում և 7-ում dns_nameservers սովորական լուծիչների ցանկը փոխարինում է սերվերի հասցեներով։ Դրա շարահյուսությունը դոմենով պայմանավորված քարտեզագրում չունի։ Վավեր բացասական պատասխանը նույնպես տարբերվում է անհասանելի լուծիչից, ուստի այլընտրանքները անհամատեղելի անվանատարածքներ որոնելու վստահելի միջոց չեն։

Հարցումների ուղղում ըստ դոմենի

Տեղական DNS փոխանցիչը կարող է արտահայտել բացակայող քաղաքականությունը։ Գոյություն ունեցող dnsmasq կարգավորումում մասնավոր վերջածանցը կարելի է ուղղել այսպես․

server=/internal.example/192.0.2.53

Փոխարինեք դոմենը և հասցեն։ Կարգավորեք հաստատված լռելյայն upstream այլ անունների համար, համապատասխան լսող և մուտքի սահմանափակումներ։ Այնուհետև Squid-ը ուղղեք այդ լուծիչին՝ օգտագործելով տեղադրված տարբերակի աջակցած կարգավորումը։

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

Եթե ծնող պրոքսին կատարում է նպատակակետի որոնումը, այդ թռիչքին անհրաժեշտ է մասնավոր անվանատարածքը։ Տեղական Squid հոսթի լուծիչը չի ուղղի ծնող պրոքսիի որոնումը։

Ստուգեք նաև բացասական դեպքը

Ընտրեք վավեր մասնավոր անուն, վավեր հանրային անուն և գոյություն չունեցող մասնավոր անուն։ Յուրաքանչյուրի համար որոշեք նախատեսված upstream-ը և արդյոք սպասվող պատասխանը հասցե է, թե բացասական պատասխան։ Վերջին դեպքը բացահայտում է ներքին բացասական պատասխանից հետո պատահական հանրային պահուստ։

Ներառեք հաճախորդի պահանջած հասցեների ընտանիքները։ Աշխատող A որոնումը չի ապացուցում, որ AAAA-ն հետևում է քաղաքականությանը կամ վերադարձնում է հասանելի նպատակակետ։ Նկատի ունեցեք նաև քեշի վիճակը․ պահված պատասխանը կարող է թաքցնել, թե որ upstream-ը կընտրեր նոր հարցումը։

Առնչվող հոդվածներ