ਕੁਬਰਨੇਟਸ ਵਿੱਚ DNS ਖੋਜ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਕੁਬਰਨੇਟਸ ਵਿੱਚ DNS ਸਮੱਸਿਆ, ਜਾਂ ਹੋਰ ਸਹੀ ਰੂਪ ਵਿੱਚ, ਪੈਰਾਮੀਟਰ ਸੈਟਿੰਗਾਂ ndots, ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਪ੍ਰਸਿੱਧ ਹੈ, ਅਤੇ ਪਹਿਲਾਂ ਹੀ ਪਹਿਲਾਂ ਨਹੀਂ Год. ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਇੱਕ ਹੋਰ ਨੋਟ ਵਿੱਚ, ਇਸਦੇ ਲੇਖਕ, ਭਾਰਤ ਵਿੱਚ ਇੱਕ ਵੱਡੀ ਬ੍ਰੋਕਰੇਜ ਕੰਪਨੀ ਤੋਂ ਇੱਕ DevOps ਇੰਜੀਨੀਅਰ, ਇੱਕ ਬਹੁਤ ਹੀ ਸਰਲ ਅਤੇ ਸੰਖੇਪ ਤਰੀਕੇ ਨਾਲ ਗੱਲ ਕਰਦਾ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਨੂੰ ਚਲਾਉਣ ਵਾਲੇ ਸਹਿਕਰਮੀਆਂ ਲਈ ਇਹ ਜਾਣਨ ਲਈ ਕੀ ਲਾਭਦਾਇਕ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ DNS ਖੋਜ

ਕੁਬਰਨੇਟਸ 'ਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੇ ਮੁੱਖ ਲਾਭਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਸਹਿਜ ਐਪਲੀਕੇਸ਼ਨ ਖੋਜ। ਸੇਵਾ ਸੰਕਲਪ (ਸੇਵਾ), ਜੋ ਕਿ ਇੱਕ ਵਰਚੁਅਲ IP ਹੈ ਜੋ ਪੌਡ IP ਪਤਿਆਂ ਦੇ ਸੈੱਟ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇ ਸੇਵਾ vanilla ਸੇਵਾ ਨਾਲ ਸੰਪਰਕ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ chocolate, ਇਹ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਵਰਚੁਅਲ IP ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ chocolate. ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ: ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੌਣ DNS ਬੇਨਤੀ ਨੂੰ ਹੱਲ ਕਰੇਗਾ chocolate ਅਤੇ ਕਿਵੇਂ?

DNS ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ CoreDNS. Kubelet ਫਾਈਲਾਂ ਵਿੱਚ ਇੱਕ ਨੇਮਸਰਵਰ ਵਜੋਂ CoreDNS ਨਾਲ ਇੱਕ ਪੌਡ ਰਜਿਸਟਰ ਕਰਦਾ ਹੈ /etc/resolv.conf ਸਾਰੀਆਂ ਫਲੀਆਂ ਜੇ ਤੁਸੀਂ ਸਮੱਗਰੀ ਨੂੰ ਦੇਖਦੇ ਹੋ /etc/resolv.conf ਕੋਈ ਵੀ ਪੋਡ, ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

search hello.svc.cluster.local svc.cluster.local cluster.local
nameserver 10.152.183.10
options ndots:5

ਇਸ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ DNS ਕਲਾਇੰਟਸ ਦੁਆਰਾ ਬੇਨਤੀਆਂ ਨੂੰ DNS ਸਰਵਰ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਫਾਈਲ ਵਿੱਚ resolv.conf ਹੇਠ ਦਿੱਤੀ ਜਾਣਕਾਰੀ ਸ਼ਾਮਿਲ ਹੈ:

  • ਨੇਮਸਰਵਰ: ਸਰਵਰ ਜਿਸ ਨੂੰ DNS ਬੇਨਤੀਆਂ ਭੇਜੀਆਂ ਜਾਣਗੀਆਂ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ CoreDNS ਸੇਵਾ ਦਾ ਪਤਾ ਹੈ;
  • ਖੋਜ: ਕਿਸੇ ਖਾਸ ਡੋਮੇਨ ਲਈ ਖੋਜ ਮਾਰਗ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਇਹ ਦਿਲਚਸਪ ਹੈ ਕਿ google.commrkaran.dev FQDN ਨਹੀਂ ਹਨ (ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਡੋਮੇਨ ਨਾਮ). ਸਟੈਂਡਰਡ ਕਨਵੈਨਸ਼ਨ ਦੇ ਅਨੁਸਾਰ ਜਿਸਦਾ ਪਾਲਣ ਜ਼ਿਆਦਾਤਰ DNS ਰੈਜ਼ੋਲਵਰ ਕਰਦੇ ਹਨ, ਸਿਰਫ ਉਹੀ ਜੋ ਇੱਕ ਬਿੰਦੂ "." ਨਾਲ ਖਤਮ ਹੁੰਦੇ ਹਨ, ਰੂਟ ਜ਼ੋਨ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ, ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ (FDQN) ਡੋਮੇਨ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਕੁਝ ਹੱਲ ਕਰਨ ਵਾਲੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਬਿੰਦੂ ਜੋੜ ਸਕਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ, mrkaran.dev. ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗਤਾ ਪ੍ਰਾਪਤ ਡੋਮੇਨ ਨਾਮ (FQDN), ਅਤੇ mrkaran.dev - ਨਹੀਂ;
  • ndots: ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਪੈਰਾਮੀਟਰ (ਇਹ ਲੇਖ ਇਸ ਬਾਰੇ ਹੈ). ndots ਬੇਨਤੀ ਨਾਮ ਵਿੱਚ ਬਿੰਦੀਆਂ ਦੀ ਥ੍ਰੈਸ਼ਹੋਲਡ ਸੰਖਿਆ ਨੂੰ "ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ" ਡੋਮੇਨ ਨਾਮ ਮੰਨੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰਾਂਗੇ ਜਦੋਂ ਅਸੀਂ DNS ਲੁੱਕਅਪ ਕ੍ਰਮ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ DNS ਖੋਜ

ਆਓ ਦੇਖੀਏ ਕਿ ਜਦੋਂ ਅਸੀਂ ਪੁੱਛਦੇ ਹਾਂ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ mrkaran.dev ਪੌਡ ਵਿੱਚ:

$ nslookup mrkaran.dev
Server: 10.152.183.10
Address: 10.152.183.10#53

Non-authoritative answer:
Name: mrkaran.dev
Address: 157.230.35.153
Name: mrkaran.dev
Address: 2400:6180:0:d1::519:6001

ਇਸ ਪ੍ਰਯੋਗ ਲਈ, ਮੈਂ CoreDNS ਲੌਗਿੰਗ ਪੱਧਰ ਨੂੰ ਸੈੱਟ ਕੀਤਾ ਹੈ all (ਜੋ ਇਸਨੂੰ ਕਾਫ਼ੀ ਸ਼ਬਦਾਵਲੀ ਬਣਾਉਂਦਾ ਹੈ)। ਆਉ ਪੌਡ ਦੇ ਲੌਗਸ ਨੂੰ ਵੇਖੀਏ coredns:

[INFO] 10.1.28.1:35998 - 11131 "A IN mrkaran.dev.hello.svc.cluster.local. udp 53 false 512" NXDOMAIN qr,aa,rd 146 0.000263728s
[INFO] 10.1.28.1:34040 - 36853 "A IN mrkaran.dev.svc.cluster.local. udp 47 false 512" NXDOMAIN qr,aa,rd 140 0.000214201s
[INFO] 10.1.28.1:33468 - 29482 "A IN mrkaran.dev.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000156107s
[INFO] 10.1.28.1:58471 - 45814 "A IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 56 0.110263459s
[INFO] 10.1.28.1:54800 - 2463 "AAAA IN mrkaran.dev. udp 29 false 512" NOERROR qr,rd,ra 68 0.145091744s

ਫੂ. ਇੱਥੇ ਦੋ ਗੱਲਾਂ ਤੁਹਾਡਾ ਧਿਆਨ ਖਿੱਚਦੀਆਂ ਹਨ:

  • ਬੇਨਤੀ ਖੋਜ ਦੇ ਸਾਰੇ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਜਵਾਬ ਵਿੱਚ ਕੋਡ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ NOERROR (DNS ਕਲਾਇੰਟ ਇਸ ਨੂੰ ਸਮਝਦੇ ਹਨ ਅਤੇ ਨਤੀਜੇ ਵਜੋਂ ਇਸਨੂੰ ਸਟੋਰ ਕਰਦੇ ਹਨ). NXDOMAIN ਮਤਲਬ ਕਿ ਦਿੱਤੇ ਗਏ ਡੋਮੇਨ ਨਾਮ ਲਈ ਕੋਈ ਰਿਕਾਰਡ ਨਹੀਂ ਮਿਲਿਆ। ਕਿਉਂਕਿ ਦ mrkaran.dev ਇੱਕ FQDN ਨਾਮ ਨਹੀਂ ਹੈ (ਦੇ ਅਨੁਸਾਰ ndots=5), ਰੈਜ਼ੋਲਵਰ ਖੋਜ ਮਾਰਗ ਨੂੰ ਵੇਖਦਾ ਹੈ ਅਤੇ ਬੇਨਤੀਆਂ ਦਾ ਕ੍ਰਮ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ;
  • ਰਿਕਾਰਡ А и АААА ਸਮਾਨਾਂਤਰ ਵਿੱਚ ਪਹੁੰਚੋ. ਤੱਥ ਇਹ ਹੈ ਕਿ ਵਿੱਚ ਇੱਕ ਵਾਰ ਦੀ ਬੇਨਤੀ /etc/resolv.conf ਮੂਲ ਰੂਪ ਵਿੱਚ, ਉਹਨਾਂ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਕਿ IPv4 ਅਤੇ IPv6 ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਮਾਨਾਂਤਰ ਖੋਜਾਂ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਤੁਸੀਂ ਵਿਕਲਪ ਨੂੰ ਜੋੜ ਕੇ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦੇ ਹੋ single-request в resolv.conf.

ਨੋਟ: glibc ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਭੇਜਣ ਲਈ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ musl - ਨਹੀਂ, ਇਸ ਲਈ ਐਲਪਾਈਨ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ।

ndots ਨਾਲ ਪ੍ਰਯੋਗ ਕਰਨਾ

ਦੇ ਨਾਲ ਥੋੜਾ ਹੋਰ ਪ੍ਰਯੋਗ ਕਰੀਏ ndots ਅਤੇ ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਪੈਰਾਮੀਟਰ ਕਿਵੇਂ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ। ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ndots ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੀ DNS ਕਲਾਇੰਟ ਡੋਮੇਨ ਨੂੰ ਸੰਪੂਰਨ ਜਾਂ ਰਿਸ਼ਤੇਦਾਰ ਸਮਝੇਗਾ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਸਧਾਰਨ google DNS ਕਲਾਇੰਟ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਇਹ ਕਿਵੇਂ ਜਾਣਦਾ ਹੈ ਕਿ ਇਹ ਡੋਮੇਨ ਸੰਪੂਰਨ ਹੈ? ਜੇਕਰ ਤੁਸੀਂ ਸੈਟ ਕਰਦੇ ਹੋ ndots 1 ਦੇ ਬਰਾਬਰ, ਗਾਹਕ ਕਹੇਗਾ: "ਓਹ, ਵਿੱਚ google ਇੱਥੇ ਇੱਕ ਵੀ ਬਿੰਦੂ ਨਹੀਂ ਹੈ; ਮੇਰਾ ਅੰਦਾਜ਼ਾ ਹੈ ਕਿ ਮੈਂ ਪੂਰੀ ਖੋਜ ਸੂਚੀ ਵਿੱਚੋਂ ਲੰਘਾਂਗਾ।" ਹਾਲਾਂਕਿ, ਜੇ ਤੁਸੀਂ ਪੁੱਛੋ google.com, ਪਿਛੇਤਰਾਂ ਦੀ ਸੂਚੀ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਣਡਿੱਠ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਬੇਨਤੀ ਕੀਤਾ ਨਾਮ ਥ੍ਰੈਸ਼ਹੋਲਡ ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ ndots (ਘੱਟੋ ਘੱਟ ਇੱਕ ਬਿੰਦੂ ਹੈ)।

ਆਓ ਇਹ ਯਕੀਨੀ ਕਰੀਏ:

$ cat /etc/resolv.conf
options ndots:1
$ nslookup mrkaran
Server: 10.152.183.10
Address: 10.152.183.10#53

** server can't find mrkaran: NXDOMAIN

CoreDNS ਲੌਗਸ:

[INFO] 10.1.28.1:52495 - 2606 "A IN mrkaran.hello.svc.cluster.local. udp 49 false 512" NXDOMAIN qr,aa,rd 142 0.000524939s
[INFO] 10.1.28.1:59287 - 57522 "A IN mrkaran.svc.cluster.local. udp 43 false 512" NXDOMAIN qr,aa,rd 136 0.000368277s
[INFO] 10.1.28.1:53086 - 4863 "A IN mrkaran.cluster.local. udp 39 false 512" NXDOMAIN qr,aa,rd 132 0.000355344s
[INFO] 10.1.28.1:56863 - 41678 "A IN mrkaran. udp 25 false 512" NXDOMAIN qr,rd,ra 100 0.034629206s

ਜਦੋਂ ਤੋਂ mrkaran ਇੱਥੇ ਇੱਕ ਵੀ ਬਿੰਦੂ ਨਹੀਂ ਹੈ, ਖੋਜ ਪਿਛੇਤਰਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਵਿੱਚ ਕੀਤੀ ਗਈ ਸੀ।

ਨੋਟ: ਅਭਿਆਸ ਵਿੱਚ ਅਧਿਕਤਮ ਮੁੱਲ ndots 15 ਤੱਕ ਸੀਮਿਤ; ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ 5 ਹੈ।

ਉਤਪਾਦਨ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ

ਜੇਕਰ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਬਹੁਤ ਸਾਰੀਆਂ ਬਾਹਰੀ ਨੈਟਵਰਕ ਕਾਲਾਂ ਕਰਦੀ ਹੈ, ਤਾਂ DNS ਸਰਗਰਮ ਟ੍ਰੈਫਿਕ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ ਰੁਕਾਵਟ ਬਣ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਨਾਮ ਰੈਜ਼ੋਲੂਸ਼ਨ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਲੋੜੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਕਰਦਾ ਹੈ (ਸਿਸਟਮ ਦੇ ਸਹੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ)। ਐਪਲੀਕੇਸ਼ਨਾਂ ਆਮ ਤੌਰ 'ਤੇ ਡੋਮੇਨ ਨਾਮਾਂ ਵਿੱਚ ਰੂਟ ਜ਼ੋਨ ਨਹੀਂ ਜੋੜਦੀਆਂ, ਪਰ ਇਹ ਇੱਕ ਹੈਕ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਭਾਵ, ਪੁੱਛਣ ਦੀ ਬਜਾਏ api.twitter.com, ਤੁਸੀਂ ਹਾਰਡਕੋਡ ਕਰ ਸਕਦੇ ਹੋ api.twitter.com. ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ (ਇੱਕ ਬਿੰਦੀ ਦੇ ਨਾਲ), ਜੋ ਕਿ DNS ਕਲਾਇੰਟਸ ਨੂੰ ਸਿੱਧੇ ਪੂਰਨ ਡੋਮੇਨ 'ਤੇ ਅਧਿਕਾਰਤ ਖੋਜ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰੇਗਾ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਬਰਨੇਟਸ ਸੰਸਕਰਣ 1.14, ਐਕਸਟੈਂਸ਼ਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ dnsConfig и dnsPolicy ਸਥਿਰ ਸਥਿਤੀ ਪ੍ਰਾਪਤ ਕੀਤੀ. ਇਸ ਤਰ੍ਹਾਂ, ਜਦੋਂ ਇੱਕ ਪੌਡ ਤਾਇਨਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੁੱਲ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ ndots, ਕਹੋ, 3 ਤੱਕ (ਅਤੇ 1 ਤੱਕ ਵੀ!) ਇਸਦੇ ਕਾਰਨ, ਇੱਕ ਨੋਡ ਦੇ ਅੰਦਰ ਹਰੇਕ ਸੰਦੇਸ਼ ਵਿੱਚ ਪੂਰਾ ਡੋਮੇਨ ਸ਼ਾਮਲ ਕਰਨਾ ਹੋਵੇਗਾ। ਇਹ ਕਲਾਸਿਕ ਟ੍ਰੇਡ-ਆਫਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਪੋਰਟੇਬਿਲਟੀ ਵਿਚਕਾਰ ਚੋਣ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਸਿਰਫ ਇਸ ਬਾਰੇ ਚਿੰਤਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਅਤਿ-ਘੱਟ ਲੇਟੈਂਸੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ DNS ਨਤੀਜੇ ਵੀ ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ ਕੈਸ਼ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਹਵਾਲੇ

ਮੈਨੂੰ ਪਹਿਲੀ ਵਾਰ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਬਾਰੇ ਪਤਾ ਲੱਗਾ K8s- ਮੁਲਾਕਾਤ25 ਜਨਵਰੀ ਨੂੰ ਆਯੋਜਿਤ ਕੀਤਾ ਗਿਆ। ਹੋਰ ਗੱਲਾਂ ਦੇ ਨਾਲ-ਨਾਲ ਇਸ ਸਮੱਸਿਆ ਬਾਰੇ ਵੀ ਚਰਚਾ ਹੋਈ।

ਹੋਰ ਖੋਜ ਲਈ ਇੱਥੇ ਕੁਝ ਲਿੰਕ ਹਨ:

  • ਵਿਆਖਿਆ, ਕੁਬਰਨੇਟਸ ਵਿੱਚ ndots=5 ਕਿਉਂ;
  • ਮਹਾਨ ਸਮੱਗਰੀ ndots ਬਦਲਣ ਨਾਲ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦਾ ਹੈ;
  • ਮਤਭੇਦ musl ਅਤੇ glibc ਰੈਜ਼ੋਲਵਰ ਵਿਚਕਾਰ.

ਨੋਟ: ਮੈਂ ਨਾ ਵਰਤਣਾ ਚੁਣਿਆ dig ਇਸ ਲੇਖ ਵਿਚ dig ਡੋਮੇਨ ਨੂੰ "ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ" (FQDN) ਬਣਾਉਂਦੇ ਹੋਏ, ਆਪਣੇ ਆਪ ਇੱਕ ਬਿੰਦੀ (ਰੂਟ ਜ਼ੋਨ ਪਛਾਣਕਰਤਾ) ਜੋੜਦਾ ਹੈ, ਨਾ ਪਹਿਲਾਂ ਇਸਨੂੰ ਖੋਜ ਸੂਚੀ ਦੁਆਰਾ ਚਲਾ ਕੇ। ਵਿਚ ਇਸ ਬਾਰੇ ਲਿਖਿਆ ਪਿਛਲੇ ਪ੍ਰਕਾਸ਼ਨਾਂ ਵਿੱਚੋਂ ਇੱਕ. ਹਾਲਾਂਕਿ, ਇਹ ਕਾਫ਼ੀ ਹੈਰਾਨੀ ਵਾਲੀ ਗੱਲ ਹੈ ਕਿ, ਆਮ ਤੌਰ 'ਤੇ, ਮਿਆਰੀ ਵਿਵਹਾਰ ਲਈ ਇੱਕ ਵੱਖਰਾ ਝੰਡਾ ਨਿਰਧਾਰਤ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

DNSing ਮੁਬਾਰਕ! ਫਿਰ ਮਿਲਦੇ ਹਾਂ!

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

ਸਰੋਤ: www.habr.com

ਇੱਕ ਟਿੱਪਣੀ ਜੋੜੋ