DNS-ওভার-HTTPS (DoH)

Google পাবলিক DNS এই শেষ পয়েন্টে দুটি স্বতন্ত্র DoH API প্রদান করে:

  • https://dns.google/dns-query – RFC 8484 (GET এবং POST)
  • https://dns.google/resolve? - JSON API (GET)

সিকিউর ট্রান্সপোর্টস ওভারভিউ পৃষ্ঠাটিতে উভয় API ব্যবহার করার জন্য curl কমান্ড লাইন উদাহরণের পাশাপাশি TLS এবং অন্যান্য বৈশিষ্ট্যের বিবরণ রয়েছে যা TLS (DoT) এবং DoH উভয় ক্ষেত্রেই সাধারণ।

DoH শুধুমাত্র IPv6-এর জন্য Google পাবলিক DNS64 পরিষেবা সমর্থিত।

Google পাবলিক DNS এপিআই কলের জন্য অনিরাপদ http: URL সমর্থন করে না।

HTTP পদ্ধতি

পাওয়া
GET পদ্ধতি ব্যবহার করে বিলম্ব কমাতে পারে, কারণ এটি আরও কার্যকরভাবে ক্যাশে করা হয়। RFC 8484 GET অনুরোধে একটি Base64Url এনকোড করা DNS বার্তা সহ একটি ?dns= ক্যোয়ারী প্যারামিটার থাকতে হবে। GET পদ্ধতি হল JSON API-এর জন্য সমর্থিত একমাত্র পদ্ধতি।
পোস্ট
POST পদ্ধতিটি শুধুমাত্র RFC 8484 API-এর জন্য সমর্থিত এবং অনুরোধের অংশে এবং DoH HTTP প্রতিক্রিয়াতে বিষয়বস্তু-টাইপ অ্যাপ্লিকেশন/dns-বার্তা সহ একটি বাইনারি DNS বার্তা ব্যবহার করে।
হেড
HEAD বর্তমানে সমর্থিত নয়, এবং একটি 400 খারাপ অনুরোধ ত্রুটি প্রদান করে ।

অন্যান্য পদ্ধতি 501 বাস্তবায়িত নয় ত্রুটি প্রদান করে।

HTTP স্থিতি কোড

Google পাবলিক DNS DoH নিম্নলিখিত HTTP স্থিতি কোড প্রদান করে:

সফলতা

200 ঠিক আছে
HTTP পার্সিং এবং DNS সমাধানকারীর সাথে যোগাযোগ সফল হয়েছে, এবং রেসপন্স বডি কন্টেন্ট হল বাইনারি বা JSON এনকোডিং-এ একটি DNS রেসপন্স, ক্যোয়ারী এন্ডপয়েন্ট, Accept হেডার এবং GET প্যারামিটারের উপর নির্ভর করে।

পুনঃনির্দেশ

301 স্থায়ীভাবে সরানো হয়েছে
ক্লায়েন্টদের Location: হেডারে দেওয়া URL-এ পুনরায় চেষ্টা করা উচিত। যদি মূল ক্যোয়ারীটি একটি POST অনুরোধ হয়, ক্লায়েন্টদের শুধুমাত্র GET দিয়ে পুনরায় চেষ্টা করা উচিত যদি নতুন URL একটি dns GET প্যারামিটার আর্গুমেন্ট নির্দিষ্ট করে; অন্যথায় ক্লায়েন্টদের POST দিয়ে পুনরায় চেষ্টা করা উচিত।

অন্যান্য কোড যেমন 302 Found, 307 Temporary Redirect বা 308 Permanent Redirect ভবিষ্যতে ব্যবহার করা হতে পারে এবং DoH ক্লায়েন্টদের চারটি কোডই পরিচালনা করা উচিত।

স্থায়ী 301 এবং 308 কোডগুলির সাথে প্রতিক্রিয়াগুলি অনির্দিষ্টকালের জন্য ক্যাশ করা উচিত এবং যদি ব্যবহারিক হয়, ব্যবহারকারীদের নতুন URL ব্যবহার করে তাদের আসল কনফিগারেশন আপডেট করার জন্য অনুরোধ করা হতে পারে৷

307 বা 308 প্রতিক্রিয়া পাওয়া POST অনুরোধগুলি সর্বদা POST দিয়ে পুনরায় চেষ্টা করা উচিত।

ত্রুটি

ত্রুটির প্রতিক্রিয়াগুলিতে এইচটিএমএল বা প্লেইন টেক্সট ব্যবহার করে, মূল অংশে HTTP স্থিতির একটি ব্যাখ্যা থাকবে।

400 খারাপ অনুরোধ
GET প্যারামিটার পার্স করার সমস্যা, অথবা একটি অবৈধ DNS অনুরোধ বার্তা। খারাপ GET প্যারামিটারের জন্য, HTTP বডির ত্রুটি ব্যাখ্যা করা উচিত। বেশিরভাগ অবৈধ ডিএনএস বার্তাগুলি একটি FORMERR সহ 200 ওকে পায়; এইচটিটিপি ত্রুটি বিকৃত বার্তাগুলির জন্য কোন প্রশ্ন বিভাগ ছাড়াই ফেরত দেওয়া হয়, একটি QR পতাকা একটি উত্তর নির্দেশ করে, বা বাইনারি ডিএনএস পার্স ত্রুটির সাথে অন্যান্য অযৌক্তিক পতাকা সমন্বয়।
413 পেলোড খুব বড়
একটি RFC 8484 POST অনুরোধের বডি সর্বাধিক 512 বাইট বার্তার আকার অতিক্রম করেছে৷
414 URI অনেক লম্বা
GET ক্যোয়ারী শিরোনামটি খুব বড় ছিল বা dns প্যারামিটারে একটি Base64Url এনকোড করা DNS বার্তা 512 বাইট সর্বাধিক বার্তা আকারের চেয়ে বেশি ছিল৷
415 অসমর্থিত মিডিয়া প্রকার
POST বডিতে কোনো application/dns-message কন্টেন্ট-টাইপ হেডার নেই।
429 অনেক বেশি অনুরোধ
ক্লায়েন্ট একটি নির্দিষ্ট সময়ের মধ্যে অনেক বেশি অনুরোধ পাঠিয়েছে। Retry-After হেডারে (সেকেন্ডে একটি আপেক্ষিক সময়) নির্দিষ্ট সময় পর্যন্ত ক্লায়েন্টদের অনুরোধ পাঠানো বন্ধ করা উচিত।
500 অভ্যন্তরীণ সার্ভার সমস্যা
Google পাবলিক DNS অভ্যন্তরীণ DoH ত্রুটি৷
501 বাস্তবায়িত হয়নি
শুধুমাত্র GET এবং POST পদ্ধতি প্রয়োগ করা হয়, অন্যান্য পদ্ধতিগুলি এই ত্রুটিটি পায়।
502 খারাপ গেটওয়ে
DoH পরিষেবা Google পাবলিক DNS সমাধানকারীদের সাথে যোগাযোগ করতে পারেনি৷

একটি 502 প্রতিক্রিয়ার ক্ষেত্রে, যদিও একটি বিকল্প Google পাবলিক ডিএনএস ঠিকানায় পুনরায় চেষ্টা করা সাহায্য করতে পারে, একটি আরও কার্যকর ফলব্যাক প্রতিক্রিয়া হবে অন্য একটি DoH পরিষেবা চেষ্টা করা, অথবা 8.8.8.8-এ প্রথাগত UDP বা TCP DNS-এ স্যুইচ করা।

DoH এর সুবিধা

HTTPS ব্যবহার করে, শুধু TLS এনক্রিপশন নয়, কিছু ব্যবহারিক সুবিধা রয়েছে:

  • ব্যাপকভাবে উপলব্ধ এবং ভাল-সমর্থিত HTTPS APIগুলি Google পাবলিক DNS এবং সম্ভাব্য ক্লায়েন্ট উভয়ের জন্যই বাস্তবায়নকে সহজ করে।
  • একটি HTTPS পরিষেবা বিদ্যমান ব্রাউজার এবং OS DNS API-এর সীমাবদ্ধতাগুলি এড়িয়ে সমস্ত DNS রেকর্ড প্রকারগুলিতে অ্যাক্সেস সহ ওয়েব অ্যাপস প্রদান করে, যা সাধারণত শুধুমাত্র হোস্ট-টু-অ্যাড্রেস লুকআপ সমর্থন করে।
  • QUIC UDP-ভিত্তিক HTTPS সমর্থন বাস্তবায়নকারী ক্লায়েন্টরা হেড-অফ-লাইন ব্লকিংয়ের মতো সমস্যাগুলি এড়াতে পারে যা TCP পরিবহন ব্যবহার করার সময় ঘটতে পারে।

DoH-এর জন্য গোপনীয়তার সর্বোত্তম অভ্যাস

DoH অ্যাপ্লিকেশনগুলির বিকাশকারীদের RFC 8484- এ বর্ণিত গোপনীয়তার সর্বোত্তম অনুশীলনগুলি বিবেচনা করা উচিত এবং নীচে প্রসারিত করা হয়েছে:

  • HTTP হেডার ব্যবহার সীমিত করুন

    HTTP শিরোনামগুলি ক্লায়েন্টের DoH বাস্তবায়ন সম্পর্কে তথ্য প্রকাশ করে এবং ক্লায়েন্টদের নাম প্রকাশ করতে ব্যবহার করা যেতে পারে। কুকি, ইউজার-এজেন্ট, এবং অ্যাকসেপ্ট-ল্যাংগুয়েজের মতো হেডারগুলি সবচেয়ে খারাপ অপরাধী, তবে পাঠানো হেডারের সেটও প্রকাশ করতে পারে। এই ঝুঁকি কমাতে, শুধুমাত্র DoH-এর জন্য প্রয়োজনীয় HTTP হেডার পাঠান: হোস্ট, কন্টেন্ট-টাইপ (পোস্টের জন্য), এবং যদি প্রয়োজন হয়, গ্রহণ করুন। ব্যবহারকারী-এজেন্টকে যেকোনো উন্নয়ন বা পরীক্ষার সংস্করণে অন্তর্ভুক্ত করা উচিত।

  • EDNS প্যাডিং বিকল্পগুলি ব্যবহার করুন৷

    ট্রাফিক বিশ্লেষণের বিরুদ্ধে সুরক্ষার জন্য কিছু সাধারণ দৈর্ঘ্যে DoH প্রশ্নগুলি প্যাড করতে EDNS প্যাডিং বিকল্পগুলি ব্যবহারের জন্য RFC 8467- এর নির্দেশিকা অনুসরণ করুন৷ HTTP/2 প্যাডিংয়ের ব্যবহারও সম্ভব কিন্তু EDNS প্যাডিংয়ের বিপরীতে, DoH সার্ভারের প্রতিক্রিয়াগুলিতে প্যাডিং প্রকাশ করবে না।

  • শুধুমাত্র গোপনীয়তা সংবেদনশীল অ্যাপ্লিকেশন বা ব্রাউজার মোডের জন্য RFC 8484 POST ব্যবহার করুন

    DoH প্রশ্নের জন্য POST ব্যবহার করা প্রতিক্রিয়াগুলির ক্যাশেবিলিটি হ্রাস করে এবং DNS লেটেন্সি বাড়াতে পারে, তাই এটি সাধারণত সুপারিশ করা হয় না। যাইহোক, গোপনীয়তা সংবেদনশীল অ্যাপ্লিকেশনগুলির জন্য ক্যাশিং হ্রাস করা সম্ভবত বাঞ্ছনীয়, এবং ব্যবহারকারী ইদানীং কোন ডোমেনগুলি পরিদর্শন করেছেন তা নির্ধারণ করার চেষ্টা করে ওয়েব অ্যাপগুলি থেকে টাইমিং আক্রমণ থেকে রক্ষা করতে পারে৷

ইস্যু

একটি বাগ রিপোর্ট করতে বা একটি নতুন বৈশিষ্ট্যের অনুরোধ করতে, দয়া করে DoH-এর জন্য একটি সমস্যা খুলুন৷