Nebula ਵਿੱਚ ਲਾਈਟਹਾਊਸ ਦੀ ਭੂਮਿਕਾ ਬਹੁਤ ਕੰਮ ਕਰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਲੋਕ ਆਪਣੇ ਆਪ ਹੋਣ ਵਾਲਾ ਮੰਨਦੇ ਹਨ, ਅਤੇ DNS ਦਾ ਜਵਾਬ ਦੇਣਾ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ ਹੈ। ਨਾਵਾਂ ਦੀ ਸੇਵਾ ਇੱਕ ਵਿਕਲਪਿਕ ਸਰੋਤਾ ਹੈ ਜੋ ਬੰਦ ਹਾਲਤ ਵਿੱਚ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਜੋ ਹੋਸਟ ਓਵਰਲੇ ਦੇ ਅੰਦਰ ਨਾਵਾਂ ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੱਲ ਕਰਦਾ ਹੈ, ਉਸ ਕੋਲ ਸਾਥੀ ਦੇ ਲੈਪਟਾਪ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਕੁਝ ਵੀ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਸ ਨੂੰ ਚਾਲੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਸ ਨੂੰ ਇਸ ਤੱਕ ਪਹੁੰਚਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਰਿਕਾਰਡ ਕਿਸਮਾਂ ਦਾ ਜਵਾਬ ਦੇਣ ਲਈ ਤੁਸੀਂ ਤਿਆਰ ਹੋ, ਕਿਉਂਕਿ ਇਹ ਦੋਵੇਂ ਜਵਾਬ ਵੱਖਰੇ ਹਨ।

ਸਰੋਤਾ ਵਿਕਲਪਿਕ ਹੈ ਅਤੇ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਬੰਦ ਹੈ

ਖੋਜ ਅਤੇ DNS ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਹਨ। ਲਾਈਟਹਾਊਸ ਸਾਥੀਆਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ ਉਨ੍ਹਾਂ ਹੋਸਟਾਂ ਬਾਰੇ ਨਾਮ-ਕਵੈਰੀ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਜਾਣਦਾ ਹੈ, ਪਰ ਉਹ ਦੂਜਾ ਭਾਗ ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਸਪੱਸ਼ਟ ਰੂਪ ਵਿੱਚ ਚਾਲੂ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਕੁਝ ਵੀ ਸਮਰੱਥ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਕਿਹੜੇ ਇੰਟਰਫੇਸ ਅਤੇ ਨੈੱਟਵਰਕ ਸਰੋਤੇ ਤੱਕ ਪਹੁੰਚਣੇ ਚਾਹੀਦੇ ਹਨ। ਜੋ DNS ਸੇਵਾ ਅਜਿਹੇ ਇੰਟਰਫੇਸ ਉੱਤੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸ ਦਾ ਤੁਸੀਂ ਇਰਾਦਾ ਨਹੀਂ ਕੀਤਾ ਸੀ, ਉਹ ਕਿਸੇ ਦੁਆਰਾ ਪੜ੍ਹੀ ਜਾਣ ਵਾਲੀ ਇੱਕ ਵੀ ਲੌਗ ਐਂਟਰੀ ਤੋਂ ਬਿਨਾਂ ਛੋਟੀ ਜਾਣਕਾਰੀ ਲੀਕ ਬਣ ਜਾਂਦੀ ਹੈ। ਫੈਸਲਾ ਹੁਣ ਲੈਣਾ ਬਾਅਦ ਵਿੱਚ ਸੀਮਤ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਸਸਤਾ ਹੈ, ਜਦੋਂ ਕੋਈ ਚੀਜ਼ ਗਲਤ ਜਵਾਬ ਉੱਤੇ ਨਿਰਭਰ ਹੋ ਜਾਂਦੀ ਹੈ। ਦੋ ਲਾਈਨਾਂ ਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਛੇ ਮਹੀਨੇ ਬਾਅਦ ਦੀ ਘਟਨਾ-ਨੋਟ ਨਾਲੋਂ ਸਮਝਾਉਣੀ ਸੌਖੀ ਹੈ।

A ਰਿਕਾਰਡ ਅਤੇ TXT ਇੱਕੋ ਦਰਸ਼ਕ ਸਾਂਝੇ ਨਹੀਂ ਕਰਦੇ

ਇਹ ਦੋ ਕਿਸਮਾਂ ਦੇ ਰਿਕਾਰਡ ਵੱਖਰੀਆਂ ਹਾਲਤਾਂ ਵਿੱਚ ਜਵਾਬ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਸੇਵਾ ਮੰਨਣਾ ਉਹੀ ਗਲਤੀ ਹੈ ਜਿਸ ਨੂੰ ਰੋਕਣ ਲਈ ਇਹ ਲੇਖ ਹੈ।

QueryWhat it returnsWho can reach it
A record for a host nameThat host Nebula IPAny host that can reach the listener, overlay or not
TXT for a host IPCertificate informationOnly over the Nebula network

ਇਹ ਅਸਮਾਨਤਾ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈ, ਲਾਪਰਵਾਹੀ ਨਹੀਂ। ਬਾਹਰਲੇ ਵਿਅਕਤੀ ਲਈ ਨਾਮ-ਤੋਂ-ਪਤਾ ਮੈਪਿੰਗ ਦਾ ਮੁੱਲ ਘੱਟ ਹੈ, ਜਦੋਂ ਕਿ ਪ੍ਰਮਾਣ ਪੱਤਰ ਮੈਟਾਡੇਟਾ ਤੁਹਾਡੇ ਓਵਰਲੇ ਦੀਆਂ ਪਛਾਣਾਂ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਸਿਰਫ ਇਸ ਲਈ ਕਿ ਇੱਕੋ ਪ੍ਰਕਿਰਿਆ ਦੋਵਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਇੱਕ ਕਤਾਰ ਤੋਂ ਦੂਜੀ ਤੱਕ ਧਾਰਨਾ ਨਾ ਲੈ ਜਾਓ।

ਇਹ ਸਿਰਫ ਲਾਈਟਹਾਊਸ ਦੇ ਆਪਣੇ ਹੋਸਟਾਂ ਬਾਰੇ ਜਵਾਬ ਦਿੰਦਾ ਹੈ

ਇਹ ਤੁਹਾਡੇ ਦਫ਼ਤਰ, ਕਲਾਊਡ VPC ਜਾਂ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ਲਈ ਆਮ ਰਿਜ਼ੋਲਵਰ ਨਹੀਂ ਹੈ। ਲਾਈਟਹਾਊਸ ਉਸ ਨੂੰ ਦਿੱਤੀ ਗਈ ਹੋਸਟ ਜਾਣਕਾਰੀ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਹਰ ਸਾਥੀ ਉੱਤੇ ਨਹੀਂ ਸਗੋਂ ਲਾਈਟਹਾਊਸ ਨੋਡਾਂ ਉੱਤੇ ਰਹਿੰਦੀ ਹੈ।

ਜਦੋਂ ਓਵਰਲੇ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨਾ ਰੱਖਣ ਵਾਲਾ ਨਾਮ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਹ ਜ਼ੋਨ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਲੱਭੋ ਜੋ ਸੱਚਮੁੱਚ ਉਸ ਦੇ ਮਾਲਕ ਹਨ। ਹੋਸਟ ਦੀ ਆਮ DNS ਕਨਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਓਵਰਲੇ ਰਿਜ਼ੋਲਵਰ ਮਿਲਾਉਣ ਨਾਲ ਅਜਿਹੀਆਂ ਅਸਫਲਤਾਵਾਂ ਬਣਦੀਆਂ ਹਨ ਜੋ ਬੇਤਰਤੀਬ ਦਿਖਦੀਆਂ ਹਨ, ਕਿਉਂਕਿ ਕੁਝ ਨਾਮ ਹੱਲ ਹੁੰਦੇ ਹਨ ਅਤੇ ਬਾਕੀਆਂ ਨੂੰ ਕੋਈ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ।

ਇਸ ਨੂੰ ਵੀ ਵੇਖੋ ਬੂਟਸਟ੍ਰੈਪ ਐਂਟਰੀ ਪੁਆਇੰਟ। ਪਹਿਲੇ ਲਾਈਟਹਾਊਸ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਹੋਸਟਨਾਮ ਆਮ ਰਾਹ ਰਾਹੀਂ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਖੋਜ ਇਸ ਉੱਤੇ ਨਿਰਭਰ ਕਰ ਸਕੇ, ਇਸ ਲਈ ਇੱਥੇ ਮੁਰਗੀ-ਅਤੇ-ਆਂਡੇ ਦੀ ਸਮੱਸਿਆ ਬਿਲਕੁਲ ਟੁੱਟੇ ਓਵਰਲੇ ਵਰਗੀ ਲੱਗਦੀ ਹੈ। ਇਹ ਉਸੇ ਤਰ੍ਹਾਂ ਰਿਪੋਰਟ ਵੀ ਕਰਦਾ ਹੈ: ਕਦੇ ਨਾ ਉੱਠਣ ਵਾਲਾ ਸਾਥੀ ਅਤੇ ਕੋਈ ਸਪੱਸ਼ਟ ਕਾਰਨ ਨਹੀਂ। ਪ੍ਰਮਾਣ ਪੱਤਰਾਂ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ ਹੱਲ ਹੋਣਾ ਜਾਂਚੋ, ਕਿਉਂਕਿ ਇਹ ਕ੍ਰਮ ਔਖੇ ਅੱਧ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਫੜਦਾ ਹੈ।

ਬਾਈਂਡ ਪਤਾ ਜਾਂਚੋ, ਫਿਰ ਬਾਹਰੋਂ ਪਰਖੋ

lighthouse.dns.host ਅਤੇ lighthouse.dns.port ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਵਿਕਲਪਿਕ ਸੇਵਾ ਕਿੱਥੇ ਸੁਣਦੀ ਹੈ। ਇਹ ਮੁੱਲ ਹੋਸਟ ਫਾਇਰਵਾਲ ਅਤੇ ਨੈੱਟਵਰਕ ਨੀਤੀ ਨਾਲ ਸਮੀਖਿਆ ਕਰੋ, ਕਿਉਂਕਿ ਬਾਈਂਡ ਪਤਾ ਇਰਾਦੇ ਦਾ ਐਲਾਨ ਹੈ ਅਤੇ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸੁਰੱਖਿਆ ਨਿਯੰਤਰਣ ਨਹੀਂ।

dig @10.42.0.1 -p 53 workstation.nebula A +short
dig @10.42.0.1 -p 53 10.42.0.7 TXT +short

ਉਨ੍ਹਾਂ ਨੈੱਟਵਰਕਾਂ ਤੋਂ ਕਵੈਰੀ ਕਰੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਇਜਾਜ਼ਤ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਲਾਈਟਹਾਊਸ ਤੋਂ ਹੀ ਨਹੀਂ। ਲਾਈਟਹਾਊਸ ਉੱਤੇ ਸਫਲ ਖੋਜ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ ਅਤੇ ਬਾਹਰਲਾ ਹੋਸਟ ਕੀ ਪੁੱਛ ਸਕਦਾ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦੀ, ਅਤੇ ਸੱਚਮੁੱਚ ਮਹੱਤਵਪੂਰਨ ਸਵਾਲ ਉਹੀ ਹੈ।

ਇਸ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਜ਼ਾਹਰ ਕਰੋ

ਨਾਮ ਅਤੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਮੈਟਾਡੇਟਾ ਲਾਭਦਾਇਕ ਕਾਰਜਸ਼ੀਲ ਜਾਣਕਾਰੀ ਹਨ, ਅਤੇ ਲਾਭਦਾਇਕਤਾ ਦੋਵੇਂ ਪਾਸੇ ਕੱਟਦੀ ਹੈ। ਤੈਅ ਕਰੋ ਕਿ ਸਰੋਤਾ ਸਿਰਫ ਓਵਰਲੇ ਲਈ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿਹੜੀਆਂ ਰਿਕਾਰਡ ਕਿਸਮਾਂ ਦੀ ਇਜਾਜ਼ਤ ਹੋਵੇ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ ਬਦਲਣ ਉੱਤੇ ਕੌਣ ਸਮੀਖਿਆ ਕਰਦਾ ਹੈ।

ਫਿਰ ਇਸ ਨੂੰ ਲਾਈਟਹਾਊਸ ਸੈਟਿੰਗਾਂ ਦੇ ਕੋਲ ਲਿਖੋ। ਰਿਜ਼ੋਲਿਊਸ਼ਨ ਅਸਫਲਤਾ ਡੀਬੱਗ ਕਰਨ ਵਾਲਾ ਅਗਲਾ ਵਿਅਕਤੀ ਨਹੀਂ ਤਾਂ ਮੰਨ ਲਵੇਗਾ ਕਿ ਸੇਵਾ ਹਮੇਸ਼ਾ ਉੱਥੇ ਹੀ ਸੀ। ਉਹ ਇਹ ਵੀ ਮੰਨ ਲਵੇਗਾ ਕਿ ਇਹ ਜਿੱਥੇ ਵੀ ਉਹ ਜਾਂਚ ਕਰਦਾ ਹੈ ਉੱਥੋਂ ਹਮੇਸ਼ਾ ਪਹੁੰਚਯੋਗ ਸੀ। ਬਾਈਂਡ ਪਤਾ, ਇਜਾਜ਼ਤ ਦਿੱਤੇ ਨੈੱਟਵਰਕ ਅਤੇ ਰਿਕਾਰਡ ਕਿਸਮਾਂ ਦਰਜ ਕਰਨ ਵਾਲਾ ਇੱਕ ਪੈਰਾ ਉਸ ਵਿਅਕਤੀ ਦੀ ਇੱਕ ਦੁਪਹਿਰ ਅਤੇ ਕੋਈ ਚੀਜ਼ ਕਿਉਂ ਬਦਲੀ ਇਹ ਪੁੱਛਣ ਵਾਲਾ ਸੁਨੇਹਾ ਤੁਹਾਡਾ ਬਚਾਉਂਦਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ