Squid Split DNS: კერძო დომენების მარშრუტიზაცია სწორი გადამწყვეტით

შიდა გადამწყვეტის პირველ ადგილზე და საჯარო გადამწყვეტის მეორეზე დაყენება Squid-ს არ ეუბნება, რომელი სახელები რომელ სივრცეს ეკუთვნის.

Squid 6-სა და 7-ში dns_nameservers ჩვეულებრივ გადამწყვეტთა სიას სერვერის მისამართებით ცვლის. მის სინტაქსში დომენის მიხედვით დაკავშირება არ არის. ვალიდური უარყოფითი პასუხი ასევე განსხვავდება მიუწვდომელი გადამწყვეტისგან, ამიტომ ალტერნატივები არ არის საიმედო გზა შეუთავსებელი სახელთა სივრცეების ძიებისთვის.

მოთხოვნების მარშრუტიზაცია დომენის მიხედვით

ლოკალურ DNS გადამცემს შეუძლია გამოხატოს დაკარგული პოლიტიკა. არსებულ dnsmasq კონფიგურაციაში კერძო სუფიქსის მარშრუტიზაცია ასე შეიძლება:

server=/internal.example/192.0.2.53

შეცვალეთ დომენი და მისამართი. დააყენეთ დამტკიცებული ნაგულისხმევი upstream სხვა სახელებისთვის, შესაბამისი მსმენელი და წვდომის შეზღუდვები. შემდეგ Squid მიუთითეთ ამ გადამწყვეტზე დაყენებული ვერსიის მხარდაჭერილი კონფიგურაციით.

ალტერნატივად გამოიყენეთ ორგანიზაციული DNS სერვისი, რომელიც ორივე სახელთა სივრცეს სწორად წყვეტს. მოერიდეთ საჯარო სარეზერვო გზას, რომელიც კერძო სახელებს ამჟღავნებს და ვერ პასუხობს მათ.

თუ მშობელი პროქსი ასრულებს დანიშნულების ძიებას, ამ ნაბიჯს კერძო სახელთა სივრცე სჭირდება. ლოკალურ Squid ჰოსტზე მდებარე გადამწყვეტი მშობლის ძიებას არ გამოასწორებს.

შეამოწმეთ უარყოფითი შემთხვევაც

აირჩიეთ ვალიდური კერძო სახელი, ვალიდური საჯარო სახელი და არარსებული კერძო სახელი. თითოეულისთვის განსაზღვრეთ განზრახული upstream და თუ მოსალოდნელი პასუხი მისამართია თუ უარყოფითი პასუხი. ბოლო შემთხვევა ამჟღავნებს შემთხვევით საჯარო სარეზერვო გზას შიდა უარყოფითი პასუხის შემდეგ.

ჩართეთ კლიენტისთვის საჭირო მისამართების ოჯახები. მუშა A ძიება არ ამტკიცებს, რომ AAAA მიჰყვება პოლიტიკას ან აბრუნებს მისაწვდომ დანიშნულებას. გაითვალისწინეთ ქეშის მდგომარეობაც: შენახულმა პასუხმა შეიძლება დამალოს, რომელ upstream-ს აირჩევდა ახალი მოთხოვნა.