ডিগ + ট্রেস কি সর্বদা সঠিক?


30

যখন কোনও ডিএনএস ক্যাশের যথার্থতা প্রশ্নবিদ্ধ হয়, তখন dig +traceকোনও ডিএনএস রেকর্ডের মুখোমুখি কোনও ইন্টারনেটের জন্য অনুমোদিত উত্তর নির্ধারণের প্রস্তাবিত উপায় হতে পারে। এটি যুক্ত হয়ে গেলে বিশেষভাবে কার্যকর বলে মনে হয় +additional, যা আঠালো রেকর্ডগুলিও দেখায়।

মাঝেমধ্যে এই বিষয়টিতে কিছুটা মতবিরোধ দেখা যায় - কিছু লোক বলে যে এটি মধ্যবর্তী নেমসার্ভারের আইপি ঠিকানাগুলি সন্ধানের জন্য স্থানীয় রেজলভারের উপর নির্ভর করে, তবে কমান্ড আউটপুট কোনও ইঙ্গিত দেয় না যে এটি রুটের প্রাথমিক তালিকার বাইরে ঘটছে that নেমসার্ভার। এটি ধরে নেওয়া যুক্তিসঙ্গত বলে মনে +traceহয় যে রুট সার্ভারগুলি শুরু করার এবং আপনার পথটি নীচে নেওয়ার উদ্দেশ্য যদি এটি হয় তবে এটি হবে না । (অন্ততপক্ষে আপনার কাছে রুট নেমসার্ভারের সঠিক তালিকা থাকলে)

dig +traceরুট নেমসার্ভারগুলির অতীতের কোনও কিছুর জন্য কি স্থানীয় রেজলভারটি সত্যই ব্যবহার করে?

উত্তর:


26

এটি স্পষ্টতই একটি মঞ্চস্থ প্রশ্নোত্তর, তবে এটি প্রায়শই মানুষকে বিভ্রান্ত করে এবং আমি বিষয়টিকে আচ্ছাদন করে কোনও আধ্যাত্মিক প্রশ্ন খুঁজে পাই না।

dig +trace: একটি মহান ডায়গনিস্টিক টুল, কিন্তু তার নকশা এক দৃষ্টিভঙ্গি ব্যাপকভাবে অনেকেই ভুল বুঝে ভাবেন করা হয় যে সার্ভার যা জানতে চাওয়া হবে আপনার সমাধানকারী লাইব্রেরি থেকে প্রাপ্ত হয় আইপি । এটি খুব সহজেই উপেক্ষা করা হয় এবং যখন আপনার স্থানীয় ক্যাশে কোনও নেমসার্ভার ক্যাশে থাকা ভুল উত্তর থাকে তখনই কেবল সমস্যা হয়ে দাঁড়ায়।


বিশদ বিশ্লেষণ

আউটপুটটির একটি নমুনা সহ এটি ভাঙ্গা সহজ; আমি প্রথম এনএস প্রতিনিধি দলের সমস্ত কিছু বাদ দেব।

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms
  • . IN NS(রুট নেমসার্ভার্স) এর প্রাথমিক ক্যোয়ারী স্থানীয় রেজলভারকে হিট করে, যা এই ক্ষেত্রে কমকাস্ট। ( 75.75.75.75) এটি স্পট করা সহজ।
  • পরবর্তী কোয়েরিটি হল serverfault.com. IN Aএবং এর বিরুদ্ধে চলে e.root-servers.net., এলোমেলোভাবে রুট নেমসার্ভারগুলির তালিকা থেকে সবেমাত্র আমরা পেয়েছি। এটির একটি আইপি ঠিকানা রয়েছে 192.203.230.10এবং যেহেতু আমরা +additionalসক্ষম করেছি এটি আঠালো থেকে আসছে বলে মনে হচ্ছে
  • যেহেতু এটি সার্ভারফল্ট ডট কমের পক্ষে অনুমোদনযোগ্য নয়, তাই এটি com.টিএলডি নেমসার্ভারগুলির কাছে অর্পিত হয় ।
  • এখানে আউটপুট থেকে যা স্পষ্ট নয় তা হ'ল আঠালো থেকে digআইপি ঠিকানাটি পাওয়া e.root-servers.net.যায় নি।

পটভূমিতে, সত্যিই এটি ঘটেছে:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+traceআঠার সাথে পরামর্শ না করে পরবর্তী হপ নেমসার্ভারের আইপি ঠিকানাটি পেতে প্রতারক এবং স্থানীয় সমাধানকারীটির সাথে পরামর্শ করে। নিনজা!

এটি সাধারণত "যথেষ্ট ভাল" এবং বেশিরভাগ মানুষের সমস্যার কারণ হবে না। দুর্ভাগ্যক্রমে, প্রান্ত মামলা আছে। যদি কোনও কারণে আপনার আপস্ট্রিম ডিএনএস ক্যাশে নেমসারভারের জন্য ভুল উত্তর সরবরাহ করে তবে এই মডেলটি পুরোপুরি ভেঙে যায়।

বাস্তব বিশ্বের উদাহরণ:

  • ডোমেনের মেয়াদ শেষ হয়
  • আঠার রেজিস্ট্রার পুনর্নির্দেশ নেমসার্ভারগুলিতে দমন করা হয়
  • বোগাস আইপিগুলি এনএস 1 এবং ns2.yourdomain.com এর জন্য ক্যাশে করা হয়
  • পুনরুদ্ধার আঠালো দিয়ে ডোমেন পুনর্নবীকরণ করা হয়
  • বোগাস নেমসারভার আইপি সহ যে কোনও ক্যাশে লোককে কোনও ওয়েবসাইটে পাঠানো অবিরত করে যা বলে যে ডোমেনটি বিক্রয়ের জন্য রয়েছে

উপরের ক্ষেত্রে, +traceপরামর্শ দিবে যে ডোমেনের মালিকের নিজস্ব নেম সার্ভারগুলিই সমস্যার উত্স এবং আপনি কোনও গ্রাহককে ভুলভাবে বলেছেন যে তাদের সার্ভারগুলি কনফিগার করা হয়েছে। এটি কিছু যা আপনি করতে (বা ইচ্ছুক) করতে পারেন তা অন্য গল্প, তবে সঠিক তথ্য থাকা জরুরী।

dig +trace একটি দুর্দান্ত সরঞ্জাম, তবে যে কোনও সরঞ্জামের মতো আপনারও এটি জানতে হবে যে এটি কী করে এবং কী করে না এবং যখন অপ্রতুল প্রমাণিত হয় তখন কীভাবে সমস্যাটি সমাধান করা যায়।


সম্পাদনা:

এটিও লক্ষ করা উচিত যে এটি dig +traceআপনাকে NSরেকর্ডগুলি সম্পর্কে সতর্ক করবে না যে CNAMEউপাধিতে বিন্দু । এটি একটি আরএফসি লঙ্ঘন যা আইএসসি বাইন্ড (এবং সম্ভবত অন্যরা) সংশোধন করার চেষ্টা করবে না। আপনার স্থানীয়ভাবে কনফিগার করা নেমসার্ভার থেকে প্রাপ্ত রেকর্ডটি +traceস্বীকার করতে পেরে এটি পুরোপুরি খুশি হবে A, অন্যদিকে BIND যদি পুরো পুনরাবৃত্তি করতে থাকে তবে এটি সার্ভারের সাথে পুরো অঞ্চলটিকে প্রত্যাখ্যান করবে।

আঠালো উপস্থিত থাকলে সমস্যা সমাধানের জন্য এটি জটিল হতে পারে; এনএস রেকর্ডগুলি রিফ্রেশ না হওয়া পর্যন্ত এটি ঠিক কাজ করবে , তারপরে হঠাৎ বিরতি। যখন কোনও উপামে একটি রেকর্ড পয়েন্ট থাকে তখন আঠালো প্রতিনিধিরা সর্বদা BIND এর পুনরাবৃত্তি ভাঙ্গবে NS


কি হবে +nssearch?
ভনব্র্যান্ড

@vonbrand +nssearchসঞ্চালিত একটি NSঅনুরোধ রেকর্ডের জন্য আপনার স্থানীয় সমাধানকারী, একটি সিরিজ দ্বারা অনুসরণ বিরুদ্ধে রেকর্ড লুকআপ A/ AAAAফিরে নেমসার্ভার প্রত্যেকের জন্য স্থানীয় সমাধানকারী বিরুদ্ধে লুক-। এটি একইভাবে ক্যাশে বোগাস নেমসার্ভার রেকর্ডগুলির পক্ষে সংবেদনশীল।
অ্যান্ড্রু বি

1
তাহলে সমাধান কী? "ডিগ ... @ সার্ভার" ব্যবহার করুন এবং প্রতিনিধিটিকে ম্যানুয়ালি অনুসরণ করবেন?
রমন

@ রমন হ্যাঁ, এটি হয় বা আপনার কোনও পুনরাবৃত্ত সার্ভারের ক্যাশে খালি করতে হবে যা আপনার হাতে রয়েছে, ক্যোয়ারী তৈরি করুন এবং ক্যাশে ফেলে দিন। (যা একটি হালকা ওজনের ক্লায়েন্টের ধারণাটিকে পরাস্ত করে) খনন প্রয়োজনীয় প্রশ্নের সংখ্যা তাত্পর্যপূর্ণভাবে হ্রাস করতে এটি করছে।
অ্যান্ড্রু বি

11

স্থানীয় রেজলভারটি রুট নেমসার্ভারগুলি সন্ধান ব্যতীত কোনও কিছুর জন্য ব্যবহার না করে ডিএনএস রেজোলিউশনটিকে ট্রেস করার আরেকটি উপায়, ডিএনএসগ্রাফ ব্যবহার করছে (সম্পূর্ণ প্রকাশ: আমি এটি লিখেছি)। এটিতে একটি কমান্ড লাইন সরঞ্জাম এবং একটি ওয়েব সংস্করণ রয়েছে, যার একটি উদাহরণ আপনি http://ip.seveas.net/dnsراف/ এ খুঁজে পেতে পারেন

সার্ভারফ্লট.কমের উদাহরণ, যা এখনই একটি ডিএনএস সমস্যা রয়েছে:

এখানে চিত্র বর্ণনা লিখুন


4
আমার মধ্যে স্টফি পেডেন্ট বলতে চাই যে এই প্রযুক্তিগতভাবে কোনও উত্তর নেই। আমার মধ্যে ডিএনএস প্রশাসক মনে করেন এটি দুর্দান্ত এবং সম্পূর্ণরূপে যত্ন করে না
অ্যান্ড্রু বি

আমি এটি একটি মন্তব্য হিসাবে পোস্ট করতে যাচ্ছিলাম, কিন্তু ইমেজ অন্তর্ভুক্ত করতে চেয়েছিলেন। আপনি যদি আরও ভাল মনে করেন তবে এটি আপনার উত্তরে নিখরচায় বদ্ধ হন।
ডেনিস কারসেমেকার

1
আমি যেমন ঠিক তেমন জিনিস নিয়ে ঠিক আছি। যদি কোনও মোড অন্যথায় অনুভব করে তবে আমি অবশ্যই একীভূত হব।
অ্যান্ড্রু বি

0

এই থ্রেডটি খুব দেরিতে হয়েছে, তবে আমি মনে করি যে কেন একটি ডিগ + ট্রেস স্থানীয় সমাধানকারীদের জন্য পুনরাবৃত্ত অনুসন্ধানগুলি ব্যবহার করে তা সরাসরি ব্যাখ্যা করা হয়নি এবং এই ব্যাখ্যাটি ডিগ + ট্রেসের ফলাফলের নির্ভুলতার সাথে প্রাসঙ্গিক।

রুট জোনের এনএস রেকর্ডগুলির জন্য প্রাথমিক পুনরাবৃত্তির ক্যোয়ারীর পরে, খনন নিম্নলিখিত শর্তে স্থানীয় রেজলভারগুলিতে পরবর্তী প্রশ্নগুলি জারি করতে পারে:

  1. পরবর্তী পুনরাবৃত্ত ক্যোয়ারীর জন্য 512 বাইটের বেশি হওয়া প্রতিক্রিয়ার আকারের কারণে একটি রেফারেল প্রতিক্রিয়া ছেঁটে ফেলা হয়

  2. খনন রেফারেল প্রতিক্রিয়ার যথাযথ বিভাগ থেকে একটি এনএস রেকর্ড নির্বাচন করে যার জন্য সংযুক্ত একটি রেকর্ড (আঠালো) অতিরিক্ত বিভাগে অনুপস্থিত

ডিগের এনএস রেকর্ড থেকে কেবল একটি ডোমেন নাম রয়েছে বলে স্থানীয় ডিএনএস সার্ভারকে জিজ্ঞাসা করে ডিগ অবশ্যই একটি আইপি ঠিকানায় নামটি সমাধান করতে হবে। এটিই মূল কারণ (শ্লেষযুক্ত, দুঃখিত)।

অ্যান্ড্রুবুর একটি উদাহরণ রয়েছে যা আমি স্রেফ বর্ণিত হিসাবে সম্পূর্ণরূপে ব্যঞ্জনবহ নয়, মূল অঞ্চলটি এনএস রেকর্ডটি বেছে নিয়েছে:

. 121459 IN NS e.root-servers.net.

একটি সম্পর্কিত রেকর্ড আছে:

e.root-servers.net. 354907 IN A 192.203.230.10

তবে নোট করুন যে ই-রুটের সাথে সম্পর্কিত এএএএ রেকর্ড নেই, পাশাপাশি কিছু অন্যান্য রুট সার্ভারের জন্য কোনও এএএএ রেকর্ড নেই।

এছাড়াও, প্রতিক্রিয়া আকার নোট করুন:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 বাইট হ'ল প্রতিক্রিয়াগুলির জন্য একটি সাধারণ আকার যা কেটে গেছে (অর্থাৎ পরবর্তী আঠালো রেকর্ডটি> 16 বাইট হত, প্রতিক্রিয়াটি 512 বাইটের বেশি রেখে দেয়)। অন্য কথায়, মূলের এনএস রেকর্ডগুলির জন্য একটি ক্যোয়ারিতে, একটি সম্পূর্ণ প্রমাণীকরণ এবং সম্পূর্ণ সংযোজন (এ এবং এএএএ উভয় রেকর্ড) 512 বাইট ছাড়িয়ে যাবে, সুতরাং যে কোনও ইউডিপি-ভিত্তিক ক্যোয়ারী যা EDNS0 বিকল্পের মাধ্যমে কোনও বৃহত্তর কোয়েরি আকার নির্দিষ্ট করে না উপরের ট্রেস শো হিসাবে কেবলমাত্র সংযোজন বিভাগে কোথাও কেটে যাওয়া একটি প্রতিক্রিয়া পান (কেবলমাত্র চ, এইচ, আই, জে, এবং কে এ এবং এএএএ আঠালো রেকর্ড রয়েছে)।

E.root-servers.net এর জন্য AAAA রেকর্ডের অভাব এবং "NS" এর প্রতিক্রিয়াটির আকার। ক্যোয়ারী দৃ strongly়ভাবে পরামর্শ দেয় যে আমি দাবি করছি যে কারণে পরবর্তী পুনরাবৃত্তি কোয়েরি করা হয়েছিল। সম্ভবত ক্লায়েন্ট ও / এস আইপিভি 6-সক্ষম, এবং এএএএ রেকর্ডগুলি পছন্দ করে - বা অন্য কোনও কারণে।

তবে যাই হোক না কেন, এই থ্রেডটি পড়ার পরে, আমি ডিগ + ট্রেস সম্পাদনের পুনরাবৃত্ত অনুসন্ধানগুলি পরে মূলটির জন্য প্রাথমিক পুনরাবৃত্ত অনুসন্ধানগুলি দেখেছি। আনুষঙ্গিক আঠালো এ / এএএএ রেকর্ড ছাড়াই এনএস রেকর্ড নির্বাচন করার মধ্যে চিঠিপত্র এবং খনন করে তারপরে স্থানীয় ডিএনএসের কাছে সেই রেকর্ডের জন্য একটি পুনরাবৃত্ত ক্যোয়ারী প্রেরণ 100% আমার অভিজ্ঞতা হিসাবে। এবং বিপরীতটি সত্য - যখন রেফারেল থেকে নির্বাচিত এনএস রেকর্ডের সাথে সম্পর্কিত আঠালো রেকর্ড থাকে তখন আমি পুনরাবৃত্ত প্রশ্নগুলি দেখিনি।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.