19 ਨਵੰ 2025·5 ਮਿੰਟ
DNS ਅਤੇ SSL ਸਮੱਸਿਆਵਾਂ ਲਈ ਕਸਟਮ ਡੋਮੇਨ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਚੈਕਲਿਸਟ
ਇਸ ਕਸਟਮ ਡੋਮੇਨ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਚੈਕਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕਰੋ DNS ਰਿਕਾਰਡ ਸਮੱਸਿਆਵਾਂ, ਪ੍ਰੋਪਾਗੇਸ਼ਨ ਦੇ ਡਿਲੇ ਅਤੇ SSL ਸਮੇਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ — ਸਧਾਰਨ ਪੁਸ਼ਟੀ ਕਦਮਾਂ ਨਾਲ।
ਇਸ ਕਸਟਮ ਡੋਮੇਨ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਚੈਕਲਿਸਟ ਦੀ ਵਰਤੋਂ ਕਰੋ DNS ਰਿਕਾਰਡ ਸਮੱਸਿਆਵਾਂ, ਪ੍ਰੋਪਾਗੇਸ਼ਨ ਦੇ ਡਿਲੇ ਅਤੇ SSL ਸਮੇਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ — ਸਧਾਰਨ ਪੁਸ਼ਟੀ ਕਦਮਾਂ ਨਾਲ।
“Custom domain not working” ਇਕ catch-all ਵਾਕ্য ਹੈ ਜੋ ਕਈ ਵੱਖ-ਵੱਖ ਫ਼ੇਲਿਅਰਾਂ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਡਾ ਬ੍ਰਾਊਜ਼ਰ ਲੱਛਣ ਦਿਖਾਉਂਦਾ ਹੈ, ਕਾਰਨ ਨਹੀਂ। ਕਿਸੇ ਵੀ ਬਦਲਾਵ ਤੋਂ ਪਹਿਲਾਂ, ਜਿਨ੍ਹਾਂ ਚੀਜ਼ਾਂ ਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੇਖ ਰਹੇ ਹੋ ਉਹ ਲਿਖੋ।
ਆਮ ਲੱਛਣਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਅਕਸਰ, ਸਿਰਫ਼ ਇਕ ਚੀਜ਼ ਗਲਤ ਹੁੰਦੀ ਹੈ:
ਟਰਬਲਸ਼ੂਟਿੰਗ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਜਗ੍ਹਾ ਦਾ ਪਹੁੰਚ ਹੈ: ਜਿੱਥੇ ਤੁਸੀਂ DNS ਰਿਕਾਰਡ ਸੋਧਦੇ ਹੋ (ਰਜਿਸਟਰਾਰ ਜਾਂ DNS ਪ੍ਰਦਾਤਾ) ਅਤੇ ਜਿੱਥੇ ਤੁਸੀਂ ਡੋਮੇਨ ਹੋਸਟਿੰਗ ਪਾਸੇ ਲਗਾਉਂਦੇ ਹੋ। ਉਦਾਹਰਨ ਵਜੋਂ, ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਡਿਪਲੋਏ ਕੀਤੀ ਐਪ ਨੂੰ ਕਸਟਮ ਡੋਮੇਨ ਨਾਲ ਜੁੜ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਡੋਮੇਨ ਲਈ DNS ਪਹੁੰਚ ਅਤੇ ਐਪ ਦੇ ਹੋਸਟਿੰਗ/ਡਿਪਲੋਯਮੈਂਟ ਸੈਟਅਪ ਵਿਚ ਡੋਮੇਨ ਸੈਟਿੰਗਾਂ ਦੀ ਪਹੁੰਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
ਕੁਝ ਫਿਕਸ ਤੁਰੰਤ ਹੁੰਦੇ ਹਨ (ਜਿਵੇਂ ਟਾਈਪੋ ਠੀਕ ਕਰਨਾ)। ਹੋਰਾਂ ਨੂੰ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ। DNS ਬਦਲਾਵ ਦਿਖਾਉਣ ਵਿੱਚ ਕੁਝ ਸਮਾਂ ਲੈ ਸਕਦੇ ਹਨ, ਅਤੇ SSL ਆਮ ਤੌਰ 'ਤੇ ਤਦ ਤੱਕ ਮੁਕੰਮਲ ਨਹੀਂ ਹੁੰਦਾ ਜਦ ਤੱਕ DNS ਠੀਕ ਤਰ੍ਹਾਂ ਨਜ਼ਰ ਨਾ ਆਵੇ ਅਤੇ ਡੋਮੇਨ ਪਹੁੰਚਯੋਗ ਨਾ ਹੋਵੇ। ਉਦਦੇਸ਼ ਇਹ ਹੈ ਕਿ ਅਨੁਮਾਨ ਲੱਗਾਉਣਾ ਬੰਦ ਕਰੋ ਅਤੇ ਹਰ ਪਰਤ ਨੂੰ ਕ੍ਰਮਵਾਰ ਪੁਸ਼ਟੀ ਕਰੋ।
ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਸਮੱਸਿਆਵਾਂ (1) ਜਿਸ ਹੋਸਟਨੇਮ ਨੂੰ ਤੁਸੀਂ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ, (2) ਜਿੱਥੇ DNS ਪ੍ਰਬੰਧਿਤ ਹੈ, ਅਤੇ (3) ਰਿਕਾਰਡ ਅਸਲ ਵਿੱਚ ਕਿੱਥੇ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ — ਇਨ੍ਹਾਂ ਦੇ ਵਿਚਕਾਰ ਮਿਲਾਪ ਨਾ ਹੋਣ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ। ਜੇ ਇਹ ਤਿੰਨ ਸਿੱਧੇ ਹੋ ਜਾਣ, ਤਾਂ ਆਮਤੌਰ 'ਤੇ SSL ਆਖਰੀ ਕਦਮ ਹੁੰਦਾ ਹੈ।
ਡੋਮੇਨਾਂ ਦੇ ਦੋ ਆਮ ਫਾਰਮ ਹੁੰਦੇ ਹਨ: root domain (example.com, ਜਿਸਨੂੰ apex ਵੀ ਕਹਿੰਦੇ ਹਨ) ਅਤੇ subdomains (www.example.com, app.example.com)। ਉਹ ਸਬੰਧਿਤ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੇ DNS ਰਿਕਾਰਡ ਅਲੱਗ ਹੋ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਇਹ ਨਾਰਮਲ ਹੈ ਕਿ www ਕੰਮ ਕਰੇ ਪਰ apex fail ਕਰੇ, ਜਾਂ ਵਿਰੋਧੀ ਹੋ ਸਕਦਾ ਹੈ।
Nameservers ਇਹ ਨਿਰਣਯ ਕਰਦੇ ਹਨ ਕਿ ਤੁਹਾਡੇ DNS ਜੋਨ ਦਾ ਇੰਚਾਰਜ ਕੌਣ ਹੈ। ਜੇ ਤੁਸੀਂ ਡੋਮੇਨ ਇਕ ਕੰਪਨੀ ਤੋਂ ਖਰੀਦਿਆ ਹੈ ਪਰ nameservers ਕਿਸੇ ਹੋਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸ ਨੂੰ ਜਿੱਥੇ nameservers ਇਸ਼ਾਰਾ ਕਰ ਰਹੇ ਹਨ ਓਥੇ DNS ਸੋਧਣਾ ਪਵੇਗਾ। banyak “I updated it but nothing changed” ਘਟਨਾਵਾਂ ਇਸ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ ਕਿ ਰਿਕਾਰਡ ਗਲਤ ਡੈਸ਼ਬੋਰਡ ਵਿੱਚ ਸੋਧੇ ਗਏ।
ਇੱਥੇ ਮੁੱਖ ਰਿਕਾਰਡ ਟਾਈਪਾਂ ਦਾ ਕੰਮ ਹੈ:
TTL "ਕਿੰਨੇ ਸਮੇਂ ਲਈ ਕੈਸ਼ ਕੀਤਾ ਜਾਵੇ" ਵਾਲਾ ਟਾਈਮਰ ਹੈ। ਘੱਟ TTL ਦਾ ਮਤਲਬ ਕਿ ਕੈਸ਼ ਤੇਜ਼ੀ ਨਾਲ ਰੀਫ੍ਰੈਸ਼ ਹੋਵੇਗਾ। ਉੱਚ TTL ਦਾ ਮਤਲਬ ਕਿ ਤੁਸੀਂ ਲੰਬਾ ਉਡੀਕਣਾ ਪੈ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਰਿਕਾਰਡ ਫਿਕਸ ਕਰ ਦਿੱਤੇ ਹੋਣ। ਕਈ ਵਾਰੀ ਪੁਰਾਣੀ ਵੈਲਯੂ ਕੁਝ ਸਮਾਂ ਦਿਖਾਈ ਦੇਣਾ ਸਧਾਰਨ ਹੈ।
ਜ਼ਦੋਂ ਇਕ ਕਸਟਮ ਡੋਮੇਨ fail ਕਰਦਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਚਾਰ ਬਕਟਾਂ ਵਿੱਚ ਵੰਡ ਸਕਦੇ ਹੋ: DNS resolve ਨਹੀਂ ਹੁੰਦਾ, DNS ਗਲਤ ਥਾਂ ਵੱਲ ਰਿਹਾ ਹੈ, SSL ਤਿਆਰ ਨਹੀਂ, ਜਾਂ ਕੁਝ ਲੋਕਾਂ ਲਈ ਇਹ ਕੇਵਲ ਕੈਸ਼ਿੰਗ ਕਾਰਨ fail ਹੁੰਦਾ ਹੈ।
ਇਸ ਫੈਸਲੇ ਦਰੱਖ਼ਤ ਦੀ ਵਰਤੋਂ ਕਰੋ:
www ਕੰਮ ਕਰਦਾ ਹੈ ਪਰ ਰੂਟ ਡੋਮੇਨ ਨਹੀਂ (ਜਾਂ ਉਸਦੇ ਉਲਟ), ਤਾਂ ਤੁਸੀਂ ਸੰਭਵਤ: ਸਿਰਫ ਇੱਕ ਹੋਸਟਨੇਮ ਸੰਰਚਿਤ ਕੀਤਾ ਹੈ, ਜਾਂ conflicting redirect ਨਿਯਮ ਹਨ।ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧੋ — ਉਸ ਅਚੂਕ ਹੋਸਟਨੇਮ ਨੂੰ ਲਿਖੋ ਜੋ fail ਕਰ ਰਿਹਾ ਹੈ (apex ਬਨਾਮ www) ਅਤੇ ਜੋ ਅਚੂਕ error message ਹੈ। ਉਨ੍ਹਾਂ ਆਟੋਮੇਟਿਕ ਡੋਮੇਨ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਵਾਲੇ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ, “cannot find host” ਅਤੇ “certificate pending” ਵਿੱਚ ਫ਼ਰਕ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ DNS ਰਿਕਾਰਡ ਠੀਕ ਕਰਨੇ ਹਨ ਜਾਂ ਸਿਰਫ SSL ਲਈ ਉਡੀਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਕਈ ਡੋਮੇਨ ਫੇਲੀਆਂ ਇੱਕ ਸਧਾਰਨ ਮਿਲਾਪ ਨਾ ਹੋਣ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ: ਤੁਸੀਂ ਇਕ ਹੋਸਟਨੇਮ ਲਈ DNS ਸੈਟਅਪ ਕੀਤਾ, ਪਰ ਤੁਸੀਂ ਦੂਜਾ ਹੋਸਟਨੇਮ ਟੈਸਟ ਕਰ ਰਹੇ ਹੋ।
ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਉਸ ਅਚੂਕ ਹੋਸਟਨੇਮ ਨੂੰ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਲਾਈਵ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਰੂਟ ਡੋਮੇਨ example.com ਵਰਗਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਸਬਡੋਮੇਨ www.example.com ਜਾਂ app.example.com ਹੁੰਦੀ ਹੈ। ਇਹ ਵੱਖ-ਵੱਖ DNS ਐਂਟ੍ਰੀਆਂ ਹਨ, ਇਸ ਲਈ “www ਚੱਲ ਰਿਹਾ ਹੈ” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਰੂਟ ਡੋਮੇਨ ਵੀ ਚੱਲੇਗਾ।
ਅਗਲਾ, ਆਪਣੇ ਹੋਸਟਿੰਗ ਪਲੇਟਫਾਰਮ ਤੋਂ ਉਮੀਦ ਕੀਤਾ ਟਾਰਗੇਟ ਲੱਭੋ। ਕੁਝ ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ IP ਐਡਰੈੱਸ ਦਿੰਦੇ ਹਨ (A ਜਾਂ AAAA ਲਈ)। ਹੋਰ ਤੁਹਾਨੂੰ ਇੱਕ ਟਾਰਗੇਟ ਹੋਸਟਨੇਮ ਦਿੰਦੇ ਹਨ (CNAME ਲਈ)। ਜੇ ਤੁਹਾਡੇ ਹੋਸਟ ਨੇ ਡੋਮੇਨ ਸੈਟਅਪ ਸਕਰੀਨ 'ਚ ਕੋਈ ਮੁੱਲ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਸਤਰ ਦੀ ਤਰ੍ਹਾਂ ਮੰਨੋ।
ਕੋਈ ਵੀ ਸੋਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਜੋ ਹਾਲ ਹੀ ਹੈ ਉਸਨੂੰ ਕੈਪਚਰ ਕਰੋ। ਸੀਧਾ ਰੱਖੋ:
ਇਹ ਵੀ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਸੀਂ ਸਹੀ DNS ਜੋਨ ਸੋਧ ਰਹੇ ਹੋ। ਗਲਤ ਡੋਮੇਨ, ਗਲਤ ਇਨਵਾਇਰੋਨਮੈਂਟ, ਜਾਂ ਗਲਤ ਪ੍ਰੋਵਾਈਡਰ ਅਕਾਊਂਟ ਵਿੱਚ ਅਪਡੇਟ ਕਰਨਾ ਆਸਾਨ ਹੈ।
ਕਈ ਸਮੱਸਿਆਵਾਂ ਸਿਰਫ਼ ਗਲਤ ਰਿਕਾਰਡ ਟਾਈਪ ਕਾਰਨ ਹੁੰਦੀਆਂ ਹਨ। ਪਹਿਲਾਂ ਦੋ ਕੇਸ ਵੱਖਰੇ ਕਰੋ: ਰੂਟ ਡੋਮੇਨ (example.com) ਅਤੇ ਸਬਡੋਮੇਨ (www.example.com)। ਬਹੁਤ ਸਾਰੇ ਪ੍ਰਦਾਤਾ ਉਤੇ ਉਹਨਾਂ ਦਾ ਵਿਵਹਾਰ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ।
A ਰਿਕਾਰਡ ਇਕ ਨਾਮ ਨੂੰ IPv4 ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਕਈ ਸੈਟਅਪ ਰੂਟ ਡੋਮੇਨ ਲਈ A ਰਿਕਾਰਡ ਵਰਤਦੇ ਹਨ ਕਿਉਂਕਿ ਕੁਝ પ્રદਾਤਾ apex 'ਤੇ CNAME ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ। ਜੇ ਤੁਹਾਡੇ ਹੋਸਟ ਨੇ ਤੁਹਾਨੂੰ IP ਦਿੱਤਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ A ਸਹੀ ਹੁੰਦਾ ਹੈ।
AAAA ਰਿਕਾਰਡ IPv6 ਵਰਜਨ ਹੈ। ਇਕ ਵਿਗੜਿਆ AAAA ਰਿਕਾਰਡ ਪੁਰਾਣੇ ਟਾਰਗੇਟ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਰਿਹਾ ਹੋਵੇ ਤਾਂ ਇਹ ਗੁੰਝਲਦਾਰ “ਮੈਨੂੰ ਚੱਲਦਾ ਹੈ” ਵਰਤਾਰਾਂ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਕੁਝ ਵਿਜ਼ਟਰ IPv6 ਉੱਤੇ ਜਾਵੇਂਗੇ ਅਤੇ ਹੋਰ IPv4 ਉੱਤੇ। ਜੇ ਤੁਹਾਡੇ ਹੋਸਟ ਨੇ IPv6 ਟਾਰਗੇਟ ਨਹੀਂ ਦਿੱਤਾ, ਤਾਂ ਗਲਤ AAAA ਹਟਾਉਣ ਨਾਲ ਅਕਸਰ inconsistent failures ਠੀਕ ਹੋ ਜਾਂਦੇ ਹਨ।
CNAME ਇੱਕ ਸਬਡੋਮੇਨ ਨੂੰ ਕਿਸੇ ਹੋਰ ਹੋਸਟਨੇਮ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ (ਅਕਸਰ www ਲਈ)। ਇਹ ਉਹ ਵੇਲੇ ਉਪਯੋਗੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਹੋਸਟ ਤੁਹਾਨੂੰ ਕਿਸੇ ਨਾਂਦਲੇ ਐਂਡਪੌਇੰਟ ਨੂੰ ਟਾਰਗੇਟ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ ਜੋ ਪਿੱਛੇ ਦੀਆਂ ਸਰਗਰਮੀ ਨੂੰ ਬਦਲ ਸਕਦਾ ਹੈ।
TXT ਰਿਕਾਰਡ ਤਸਦੀਕ ਅਤੇ ਚੈਲੈਂਜ (ਕਈ ਵਾਰੀ SSL ਚੈਲੈਂਜ) ਲਈ ਹੁੰਦੇ ਹਨ। ਆਮ ਗਲਤੀਆਂ ਵਿੱਚ TXT ਨੂੰ ਗਲਤ ਨਾਮ 'ਤੇ ਰੱਖਣਾ (root ਬਨਾਮ _acme-challenge ਬਨਾਮ ਕਿਸੇ ਸਬਡੋਮੇਨ), ਵਾਧੂ ਖਾਲੀ ਥਾਵਾਂ, ਜਾਂ ਗਲਤ ਮੁੱਲ ਪੇਸਟ ਕਰਨਾ ਸ਼ਾਮਲ ਹੈ।
ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ, conflicts ਦੀ ਖੋਜ ਕਰੋ। ਇਹ ਉਹਨਾਂ ਵਿਚੋਂ ਹਨ ਜੋ ਸਭ ਤੋਂ ਵਧ ਕੇ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਦੇ ਹਨ:
ਕਈ “custom domain not working” ਮਾਮਲੇ ਰਿਕਾਰਡ ਮੁੱਲ ਲਈ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਇਸ ਲਈ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਰਿਕਾਰਡ ਗਲਤ ਪ੍ਰਦਾਤਾ 'ਤੇ ਜੋੜੇ ਗਏ। ਜੇ ਤੁਹਾਡਾ ਡੋਮੇਨ Provider A ਦੇ nameservers ਵਰਤਦਾ ਹੈ, ਤਾਂ Provider B ਦੇ ਡੈਸ਼ਬੋਰਡ 'ਚ ਰਿਕਾਰਡ ਬਦਲਣਾ ਕੁਝ ਨਹੀਂ ਕਰੇਗਾ, ਭਾਵੇਂ ਉਥੇ ਰਿਕਾਰਡ ਸਹੀ ਹੀ ਲੱਗਦੇ ਹੋਣ।
ਪਤਾ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਡੋਮੇਨ ਅਸਲ ਵਿੱਚ ਕਿਹੜੇ nameservers ਵਰਤ ਰਿਹਾ ਹੈ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਰਜਿਸਟਰਾਰ ਦੇ ਡੋਮੇਨ ਸੈਟਿੰਗਜ਼ 'ਚ “Nameservers” ਹਿੱਸੇ 'ਚ ਵੇਖ ਸਕਦੇ ਹੋ। ਦੂਜੇ ਰਾਏ ਲਈ, ਆਪਣੇ ਕੰਪਿਊਟਰ ਤੋਂ DNS ਨੂੰ ਸਧਾ ਪੁੱਛੋ:
dig NS example.com
ਉਸ ਕਮਾਂਡ ਦੁਆਰਾ ਵਾਪਸ ਕੀਤੇ nameservers ਹੀ ਅਧਿਕਾਰਤ ਹਨ।
ਇੱਕ ਛੋਟੀ ਸੰਤੁਸ਼ਟੀ ਜाँच:
ns1... ਅਤੇ ns2... ਵਰਗੇ nameservers ਦਿੰਦਾ ਹੈ, ਤਾਂ ਉਹੀ ਮੂਲ ਮੁੱਲ ਰਜਿਸਟਰਾਰ `ਤੇ ਦਿੱਤੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।ਜੇ ਤੁਸੀਂ ਗਲਤ ਪ੍ਰਦਾਤਾ 'ਤੇ ਰਿਕਾਰਡ ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਅਕਸਰ ਤੁਸੀਂ ਦੋ ਡੈਸ਼ਬੋਰਡ ਦੇਖੋਗੇ ਜੋ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ। ਕੇਵਲ ਅਧਿਕਾਰਤ nameservers ਮੈਟਰ ਕਰਦੇ ਹਨ।
ਨਾਮਸਰਵਰ ਰਜਿਸਟਰਾਰ 'ਤੇ ਬਦਲ ਰਹੇ ਹੋਣ 'ਤੇ ਵੀ ਦੇਰੀਆਂ ਆ ਸਕਦੀਆਂ ਹਨ। ਟ੍ਰਾਂਜ਼ਿਸ਼ਨ ਵਿਂਡੋ ਦੌਰਾਨ ਨਤੀਜੇ ਅਲੱਗ-ਅਲੱਗ ਦਿਸ ਸਕਦੇ ਹਨ ਜਿੱਥੇ ਤੁਸੀਂ ਟੇਸਟ ਕਰ ਰਹੇ ਹੋ। ਜੇ nameservers ਅਜੇ ਵੀ ਬਦਲ ਰਹੇ ਹਨ, ਤਦ ਤੱਕ ਰਿਕਾਰਡ ਸੋਧਣ ਰੋਕ ਦਿਓ ਜਦ ਤੱਕ nameserver ਸੈਟ ਸਥਿਰ ਨਾ ਹੋ ਜਾਵੇ, ਫਿਰ ਅੱਗੇ ਵਧੋ।
“Propagation” ਕੋਈ ਇੱਕ ਬਟਨ ਨਹੀਂ ਹੈ। ਇਹ DNS caches ਦੀ ਲੜੀ ਹੈ (ISP, ਫੋਨ ਕੈਰੀਅਰ, ਪਬਲਿਕ ਰਿਜ਼ੋਲਵਰ, ਅਤੇ ਤੁਹਾਡੇ ਆਪਣੇ ਡਿਵਾਈਸ) ਜੋ ਵੱਖ-ਵੱਖ ਰਫ਼ਤਾਰ ਨਾਲ ਅਪਡੇਟ ਹੁੰਦੇ ਹਨ। ਇਸੀ ਕਾਰਨ ਹੈ ਕਿ ਤੁਹਾਡਾ ਡੋਮੇਨ ਇੱਕ ਸਹਯੋਗੀ ਲਈ ਚੱਲ ਸਕਦਾ ਹੈ ਪਰ ਤੁਹਾਡੇ ਲਈ fail ਕਰ ਸਕਦਾ ਹੈ।
TTL (time to live) ਦੱਸਦਾ ਹੈ ਕਿ caches ਕਿਸ ਸਮੇਂ ਲਈ ਇਕ ਜਵਾਬ ਰੱਖ ਸਕਦੇ ਹਨ। ਜੇ ਪੁਰਾਣਾ TTL 1 ਘੰਟਾ ਸੀ, ਤਾਂ ਕੁਝ ਲੋਕ ਕਾਫੀ ਸਮਾਂ ਤੱਕ ਪੁਰਾਣੀ ਵੈਲਯੂ ਦੇਖਦੇ ਰਹਿ ਸਕਦੇ ਹਨ। TTL ਘਟਾਉਣਾ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ TTL ਘਟਾਇਆ ਹੋਵੇ।
ਕੈਸ਼ਿੰਗ ਦੇ ਦੇਰੀ ਨੂੰ ਗਲਤੀਆਂ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ ਕੁਝ ਸਧਾਰਨ ਚੈੱਕ ਕਰੋ:
ਜੇ ਜੇਕਰ ਰਿਕਾਰਡ ਕਿਸੇ ਵੀ ਥਾਂ ਤੇ ਗਲਤ ਹੈ (ਗਲਤ IP, www ਗਾਇਬ, ਪੁਰਾਣਾ CNAME), ਤਾਂ ਉਸਨੂੰ ਠੀਕ ਕਰੋ। ਜੇ ਰਿਕਾਰਡ ਜ਼ਿਆਦਾਤਰ ਥਾਵਾਂ 'ਚ ਸਹੀ ਲੱਗਦੇ ਹਨ ਪਰ ਇਕ ਨੈੱਟਵਰਕ ਹਜੇ ਵੀ ਪੁਰਾਣੀ ਵੈਲਯੂ ਦਿਖਾ ਰਿਹਾ ਹੈ, ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਕੈਸ਼ਿੰਗ ਦੀ ਦੇਰੀ ਹੈ।
SSL ਸਰਟੀਫਿਕੇਟ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਸਧਾਰਨ ਕਾਰਨ ਲਈ fail ਹੁੰਦੇ ਹਨ: ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਦਾਤਾ ਡੋਮੇਨ ਨੂੰ ਤਦ ਤੱਕ ਵੈਰੀਫਾਈ ਨਹੀਂ ਕਰ ਸਕਦਾ ਜਦ ਤੱਕ DNS ਲਗਾਤਾਰ ਸਹੀ ਢੰਗ ਨਾਲ ਟਾਰਗੇਟ ਵੱਲ ਨਜ਼ਰ ਨਾ ਆਵੇ।
ਆਮ ਕ੍ਰਮ ਸਿੱਧਾ ਹੈ:
ਆਮ ਰੁਕਾਵਟਾਂ ਅਕਸਰ ਝਲਕਦੀਆਂ ਹਨ। ਗਲਤ A ਜਾਂ CNAME ਟਾਰਗੇਟ validation checks ਨੂੰ ਗਲਤ ਸਰਵਰ ਵੱਲ ਭੇਜਦੇ ਹਨ। ਪੁਰਾਣਾ AAAA ਰਿਕਾਰਡ ਤੁਹਾਡੇ ਸਹੀ A ਰਿਕਾਰਡ ਨੂੰ override ਕਰ ਸਕਦਾ ਹੈ ਕੁਝ ਯੂਜ਼ਰਾਂ ਲਈ, ਇਸ ਲਈ HTTPS ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਲਈ fail ਹੋ ਸਕਦਾ ਹੈ। ਲੋੜੀਂਦਾ TXT ਰਿਕਾਰਡ ਗਾਇਬ ਹੋਣਾ ਪਲੇਟਫਾਰਮ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਤੋਂ ਰੋਕ ਸਕਦਾ ਹੈ।
ਲੱਛਣਾਂ ਲਈ ਇਹ ਵੱਖ ਕਰੋ ਕਿ "ਹਜੇ ਜਾਰੀ ਹੋ ਰਿਹਾ ਹੈ" ਜਾਂ "ਗਲਤ ਸੈੱਟ ਹੈ":
ਜਦ ਤੱਕ ਤੁਸੀਂ ਉਡੀਕ ਕਰ ਰਹੇ ਹੋ, ਰਿਕਾਰਡਾਂ ਨੂੰ ਬਾਰ-ਬਾਰ ਫਲਿੱਪ ਨਾ ਕਰੋ। ਹਰ ਬਦਲਾਅ ਕਲਾਕ ਗੁੰਮ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਇੱਕ ਕੱਟ-ਦੁਨੀਆ ਬਣ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਵੱਖ-ਵੱਖ ਨੈੱਟਵਰਕ ਵੱਖ-ਵੱਖ ਜਵਾਬ ਵੇਖਦੇ ਹਨ। ਇਕ ਵਾਰੀ ਸਹੀ ਰਿਕਾਰਡ ਸੈਟ karo, ਫਿਰ DNS resolution ਅਤੇ verification ਨੂੰ ਸਵੱਛ ਚੈੱਕ ਕਰੋ ਜਦ ਤੱਕ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਨਾ ਹੋ ਜਾਵੇ।
ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਫਲੋ ਵਰਗਾ ਹੈ: DNS ਟਾਰਗੇਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਗ਼ਲਤ AAAA ਰਿਕਾਰਡ ਹਟਾਓ ਜੇ ਮੌਜੂਦ ਹਨ, ਅਤੇ DNS ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ SSL ਲਈ ਸਮਾਂ ਦਿਓ।
ਚੰਗੀ ਟਰਬਲਸ਼ੂਟਿੰਗ ਜ਼ਿਆਦਾਤਰ ਮੁਕਾਬਲਾ ਹੈ: ਜੋ ਤੁਸੀਂ ਵੇਖਦੇ ਹੋ ਵਿਰੁੱਧ ਜੋ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ। "ਇਹ ਮੇਰੇ ਫੋਨ 'ਤੇ ਲੋਡ ਹੁੰਦਾ ਹੈ" 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ। ਨਿਰੰਤਰ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਚੈੱਕ ਵਰਤੋਂ।
ਇੱਕ DNS ਲੁੱਕਅੱਪ ਟੂਲ (ਜਿਵੇਂ nslookup ਜਾਂ dig) ਵਰਤੋਂ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਵਾਪਸ ਕੀਤਾ ਗਿਆ ਮੁੱਲ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਨਾਲ ਮਿਲਦਾ ਹੈ (A ਜਾਂ AAAA ਲਈ IP, CNAME ਲਈ ਹੋਸਟਨੇਮ, TXT ਲਈ ਟੋਕਨ)।
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
ਉਹ ਦੋਨਾਂ ਨਾਮਾਂ ਦੀ ਜਾਂਚ ਕਰੋ ਜੋ ਤੁਸੀਂ ਵਰਤ ਸਕਦੇ ਹੋ: apex (example.com) ਅਤੇ www (www.example.com)। ਇਹ ਆਮ ਹੈ ਕਿ ਇਕ ਸਹੀ ਹੋਵੇ ਪਰ ਦੂਜਾ ਪੁਰਾਣੇ ਪਤੇ ਵੱਲ ਦਿਖੇ।
apex ਅਤੇ www ਦੋਹਾਂ ਲਈ http:// ਅਤੇ https:// ਖੋਲ੍ਹੋ। ਤੁਹਾਨੂੰ ਇੱਕ ਸਾਫ "home" ਡੋਮੇਨ ਅਤੇ ਇੱਕ ਸਾਫ਼ ਰੀਡਾਇਰੈਕਟ ਚਾਹੀਦਾ ਹੈ।
www) ਅਤੇ ਦੂਜੇ ਨੂੰ ਉਸ ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰੋ।ਜੇ ਨਤੀਜੇ ਨੈੱਟਵਰਕ ਨਾਲ ਵੱਖਰੇ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਸੰਭਵਤ: ਕੈਸ਼ਿੰਗ ਜਾਂ ਪ੍ਰੋਪਾਗੇਸ਼ਨ ਦੇਖ ਰਹੇ ਹੋ। ਛੋਟਾ ਲੌਗ ਰੱਖੋ: ਤੁਸੀਂ ਕੀ ਬਦਲਿਆ, ਕਿੱਥੇ ਬਦਲਿਆ, ਸਮਾਂ, ਅਤੇ ਤੁਹਾਡੇ ਨਿਰੀਖਣ।
ਜ਼ਿਆਦਾਤਰ DNS ਅਤੇ SSL ਸਮੱਸਿਆਵਾਂ ਰਾਜ਼ ਨਹੀਂ ਹੁੰਦੀਆਂ। ਉਹਨਾਂ ਦੇ ਪਿੱਛੇ ਛੋਟੀਆਂ ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਗਲਤ ਚੀਜ਼ ਦੇਖਣ ਜਾਂ ਬੇਜ਼ਰੂਰ ਤਅਦਿਲ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀਆਂ ਹਨ।
ਸਭ ਤੋਂ ਆਮ ਸਮਾਂ ਖਪਾਉਣ ਵਾਲੀ ਗਲਤੀ ਹੈ ਦੋ ਥਾਵਾਂ 'ਚ DNS ਸੋਧਣਾ। ਇਹ ਅਕਸਰ nameservers ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਹੁੰਦਾ ਹੈ: ਤੁਸੀਂ ਰਜਿਸਟਰਾਰ 'ਤੇ ਰਿਕਾਰਡ ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਪਰ DNS ਅਸਲ ਵਿੱਚ ਹੋਰ ਥਾਂ ਤੇ ਹੋਸਟ ਹੋ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਡੈਸ਼ਬੋਰਡ 'ਚ ਸਭ ਕੁਝ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਫਿਰ ਭੀ ਕੁਝ ਪਬਲਿਕ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਨਹੀਂ।
ਹੋਰ ਇੱਕ ਕਲਾਸਿਕ ਗਲਤੀ root ਡੋਮੇਨ 'ਤੇ CNAME ਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਹੈ ਜੇਕਰ ਪ੍ਰਦਾਤਾ ਉਸਨੂੰ ਸਹਾਰਾ ਨਹੀਂ ਦਿੰਦਾ। ਤੁਹਾਨੂੰ A ਰਿਕਾਰਡ, ਜਾਂ ALIAS/ANAME ਸਟਾਈਲ ਰਿਕਾਰਡ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਪ੍ਰਦਾਤਾ ਆਫਰ ਕਰੇ।
IPv6 ਵੀ headache ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਪੁਰਾਣਾ AAAA ਰਿਕਾਰਡ ਛੱਡ ਦੇਣਾ ਇੱਕ ਗਲਤ ਸਰਵਰ ਵੱਲ ਕੁਝ ਵਿਜ਼ਟਰ ਭੇਜ ਸਕਦਾ ਹੈ ਜਦ ਕਿ ਹੋਰ IPv4 ਨਾਲ ਸਹੀ ਟਾਰਗੇਟ ਤੇ ਪਹੁੰਚ ਕਰ ਰਹੇ ਹਨ।
“ਜਿਸ ਲਈ ਕੇਸ-ਇਨ-ਕੇਸ” ਰਿਕਾਰਡਾਂ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ। ਜ਼ਿਆਦਾ A ਰਿਕਾਰਡ ਇੱਕ ਅਚਾਨਕ ਲੋਡ ਬੈਲੈਂਸਿੰਗ ਵਾਂਗ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ ਜੇਕਰ ਇਕ ਟਾਰਗੇਟ ਗਲਤ ਹੋਵੇ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਇੱਕ hosted app ਨੂੰ custom domain apont ਕਰ ਰਹੇ ਹੋ।
ਇੱਕ ਆਖਰੀ ਨਿਯਮ: ਘੜੀ ਰੀਸੈੱਟ ਕਰਨਾ ਬੰਦ ਕਰੋ।
ਛੋਟੇ, ਸ਼ਾਂਤ ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਬਿਹਤਰ ਹਨ ਬਨਾਮ ਇਕ-ਲਗਾਤਾਰ ਟਵੀਕਿੰਗ।
ਤੁਸੀਂ ਨਵੀਂ ਐਪ ਲਾਂਚ ਕਰਦੇ ਹੋ ਅਤੇ ਦੋਹਾਂ example.com ਅਤੇ www.example.com ਸੈਟਅਪ ਕਰਦੇ ਹੋ। ਕੁਝ ਮਿੰਟ ਬਾਅਦ, www.example.com ਠੀਕ ਲੋਡ ਹੁੰਦਾ ਹੈ, ਪਰ ਰੂਟ ਡੋਮੇਨ DNS error ਦਿਖਾਉਂਦਾ ਹੈ, ਪੁਰਾਣੀ ਸਾਈਟ ਲੋਡ ਕਰਦਾ ਹੈ, ਜਾਂ HTTPS pending ਰਹਿੰਦਾ ਹੈ। ਇਹ pattern ਆਮ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਕਾਰਨ ਹੁੰਦਾ ਹੈ।
ਬੋਰਨਿੰਗ ਸਵਾਲ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: ਕੀ ਤੁਸੀਂ ਸਹੀ ਜਗ੍ਹਾ 'ਤੇ DNS ਸੋਧ ਰਹੇ ਹੋ? ਜੇ ਤੁਹਾਡਾ ਡੋਮੇਨ ਇਕ ਕੰਪਨੀ 'ਤੇ ਰਜਿਸਟਰ ਹੈ ਪਰ DNS ਹੋਰ ਥਾਂ 'ਤੇ ਹੋਸਟ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਾਰਾ ਦਿਨ ਰਿਕਾਰਡ ਬਦਲ ਸਕਦੇ ਹੋ ਪਰ ਕੁਝ ਨਹੀਂ ਹੋਵੇਗਾ। ਪਹਿਲਾਂ nameservers ਚੈੱਕ ਕਰੋ, ਫਿਰ ਉਹਨਾਂ nameservers ਵਾਲੇ ਪ੍ਰੋਵਾਈਡਰ ਦੀ DNS ਪੈਨਲ ਖੋਲ੍ਹੋ।
ਅਗਲੇ ਕਦਮ ਦੇ ਤੌਰ 'ਤੇ ਦੋ hostnames ਦੀ ਤੁਲਨਾ ਕਰੋ। ਆਮ ਤੌਰ 'ਤੇ www CNAME ਹੁੰਦਾ ਹੈ। ਰੂਟ ਡੋਮੇਨ ਮਸ਼ੱਕਲ-ਭਰਿਆ ਹੈ: ਕਈ ਪ੍ਰਦਾਤਾ apex 'ਤੇ CNAME ਦੀ ਆਗਿਆ ਨਹੀਂ ਦਿੰਦੇ, ਇਸ ਲਈ ਅਕਸਰ ਉਹਨਾਂ ਨੂੰ IP ਲਈ A ਰਿਕਾਰਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਾਂ ALIAS/ANAME-ਸ਼ੈਲੀ ਰਿਕਾਰਡ ਜੇ ਪ੍ਰਦਾਤਾ ਪੇਸ਼ ਕਰੇ।
ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਾਤਮਕ ਫੈਸਲਾ ਪਾਥ ਵੈਹਿ:
example.com ਦੇ ਕੋਲ ਕੋਈ ਰਿਕਾਰਡ ਨਹੀਂ (ਜਾਂ ਇਹ ਕਿਸੇ ਹੋਰ ਥਾਂ ਵੱਲ ਪੁੱਛਦਾ ਹੈ)? apex ਰਿਕਾਰਡ ਠੀਕ ਕਰੋ।ਸਹੀ ending ਸਧਾਰਨ ਹੁੰਦਾ ਹੈ: ਦੋਹਾਂ example.com ਅਤੇ www.example.com ਉਸੇ ਐਪ ਨੂੰ ਲੈ ਜਾਂਦੇ ਹਨ, ਇੱਕ canonical ਹੈ (ਦੂਜਾ ਉਸਨੂੰ redirect ਕਰਦਾ ਹੈ), ਅਤੇ HTTPS ਵੈਧ ਹੈ।
ਜਦੋਂ ਡੋਮੇਨ ਸੈਟਅਪ fail ਹੋਵੇ, ਬਹੁਤ ਸਾਰੇ ਫਿਕਸ ਕੁਝ ਤੁਰੰਤ ਚੈੱਕਾਂ ਤੋਂ ਆਉਂਦੇ ਹਨ। ਕੋਈ ਵੀ ਹੋਰ ਸੋਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਇਹਨਾਂ ਨੂੰ ਚਲਾਓ।
DNS ਬਿਲਕੁਲ ਸਹੀ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ SSL ਦੀ ਜਾਂਚ ਕਰੋ। ਕਈ ਪਲੇਟਫਾਰਮ ਸਿਰਫ਼ ਉਸ ਵੇਲੇ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨਗੇ ਜਦੋਂ ਉਹ ਤੁਹਾਡੇ ਡੋਮੇਨ ਨੂੰ ਲਗਾਤਾਰ ਸਹੀ ਟਾਰਗੇਟ ਵੱਲ resolve ਕਰਦੇ ਵੇਖਣ। ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਸਧਾਰਨ ਦੇਰੀ ਨੂੰ ਗਲਤ ਤਰ੍ਹਾਂ ਇੱਕ ਵਾਸਤਵਿਕ ਗਲਤੀ ਸਮਝ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਡਿਪਲੋਏ ਕੀਤੀ ਐਪ ਲਈ ਕਸਟਮ ਡੋਮੇਨ ਜੁੜ ਰਹੇ ਹੋ, ਤਾਂ domain setup ਸਕਰੀਨ ਨੂੰ ਉਮੀਦ ਟਾਰਗੇਟ ਲਈ ਸਤਰ ਮੰਨੋ, ਫਿਰ authoritative DNS ਵਿੱਚ ਠੀਕ ਮਿਲਾਓ ਅਤੇ DNS propagate ਹੋਣ ਦੇ ਬਾਅਦ ਹੀ SSL ਸਥਿਤੀ ਦੁਬਾਰਾ ਚੈੱਕ ਕਰੋ।
DNS ਅਤੇ SSL ਗਲਤੀਆਂ ਨੂੰ ਦੁਹਰਾਉਣ ਤੋਂ ਬਚਾਉਣ ਦਾ ਤੇਜ਼ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਹਰ ਪ੍ਰੋਜੈਕਟ ਲਈ ਇਕ ਛੋਟੀ “ਡੋਮੇਨ ਸੈਟਅਪ ਨੋਟ” ਰੱਖੋ। ਇਹ ਇਕ ਦੁਬਾਰਾ ਵਰਤਣ ਯੋਗ ਰਨਬੁੱਕ ਹੈ ਜੋ ਤੁਸੀਂ ਅਗਲੀ ਵਾਰ ਲਾਂਚ ਕਰਦੇ ਸਮੇਂ ਨਕਲ ਕਰ ਸਕਦੇ ਹੋ।
ਇਸਨੂੰ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਡੌਕਸ 'ਚ ਰੱਖੋ ਅਤੇ DNS ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਭਰੋ:
ਲਾਂਚ ਦੌਰਾਨ, ਇੱਕ ਵਿਅਕਤੀ ਨੂੰ DNS ਮਾਲਕ ਬਣਾਓ। DNS ਬਹੁਤ ਵਾਰੀ ਤਦ ਭੰਨ-ਭਰਤ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੋ ਲੋਕ ਵੱਖ-ਵੱਖ ਚੀਜ਼ਾਂ ਇੱਕੋ ਸਮੇਂ "ਠੀਕ" ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ nameservers ਬਦਲ ਰਿਹਾ ਹੋਵੇ ਜਿਸ ਵੇਲੇ ਦੂਜਾ ਅਕਾਉਂਟ ਵਿੱਚ ਰਿਕਾਰਡ ਸੋਧ ਰਿਹਾ ਹੋਵੇ)।
ਹੋਸਟਿੰਗ ਪਾਸੇ, ਸੁਰੱਖਿਅਤ ਵਾਪਸੀ ਯੋਜਨਾ ਬਣਾਓ। ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshots ਜਾਂ rollback ਸਹਾਇਤ ਕਰਦਾ ਹੈ, ਤਾਂ routing ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ snapshot ਲਓ ਤਾਂ ਜੋ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਪਿਛਲੇ ਜਾਣ-ਪਹਿਚਾਨੇ ਸਥਿਤੀ 'ਤੇ ਵਾਪਿਸ ਜਾ ਸਕੋ। ਜੇ ਤੁਸੀਂ Koder.ai 'ਤੇ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ Planning Mode ਵਰਤ ਕੇ ਡੋਮੇਨ ਕਦਮ ਲਿਖ ਸਕਦੇ ਹੋ, ਉਹਨਾਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਲਾਗੂ ਕਰੋ, ਅਤੇ ਜੇ ਕੋਈ ਬਦਲਾਅ production ਤੋੜਦਾ ਹੈ ਤਾਂ ਰੋਲਬੈਕ ਕਰੋ।
ਜੇ ਤੁਸੀਂ DNS ਪੁਸ਼ਟੀ ਕਰ ਲਈ ਹੈ ਅਤੇ ਫਿਰ ਵੀ fail ਵੇਖ ਰਹੇ ਹੋ, ਤਾਂ guessing ਬੰਦ ਕਰੋ ਅਤੇ ਸਬੂਤ ਨਾਲ escalate ਕਰੋ:
ਜਦੋਂ ਤੁਸੀਂ escalate ਕਰੋ, ਤਾਂ ਹੋਸਟਨੇਮ, ਉਮੀਦ ਕੀਤੇ ਰਿਕਾਰਡ, ਮੌਜੂਦਾ ਰਿਜ਼ੋਲਵਰ ਨਤੀਜੇ, ਅਤੇ timestamps ਸ਼ਾਮਲ ਕਰੋ। ਇਹ ਧੀਰੇ-ਧੀਰੇ ਬੈਕ-ਅੈਂਡ-ਫੋਰਥ ਨੂੰ ਤੇਜ਼ ਫਿਕਸ ਵਿਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਚੇਨ ਦੀ ਕਿਸੇ ਇਕ ਪਰਤ ਵਿੱਚ ਗਲਤੀ ਹੈ: DNS ਰੈਜ਼ੋਲ੍ਵ ਨਹੀਂ ਹੋ ਰਿਹਾ, DNS ਗ਼ਲਤ ਟਾਰਗੇਟ ਵੱਲ ਜਾ ਰਿਹਾ ਹੈ, ਸਰਵਰ/ਹੋਸਟ ਤੁਹਾਡੇ ਹੋਸਟਨੇਮ ਨੂੰ ਨਹੀਂ ਜਾਣਦਾ, ਜਾਂ HTTPS/SSL ਅਜੇ ਜਾਰੀ ਨਹੀਂ ਹੋਇਆ। ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਉਹ ਅਚੂਕ ਤਰ੍ਹਾਂ ਦੱਸੋ ਜੋ ਤੁਸੀਂ ਵੇਖ ਰਹੇ ਹੋ ਅਤੇ ਉਹ ਹੌਸਟਨੇਮ ਜੋ ਤੁਸੀਂ ਟਾਈਪ ਕੀਤਾ (apex ਬਨਾਮ www)।
www.example.com ਅਤੇ example.com ਵੱਖ-ਵੱਖ ਹੋਸਟਨੇਮ ਹਨ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ DNS ਐਂਟ੍ਰੀਆਂ ਅਲੱਗ ਹੋ ਸਕਦੀਆਂ ਹਨ। ਆਮ ਤੌਰ 'ਤੇ www ਲਈ CNAME ਸਹੀ ਹੁੰਦਾ ਹੈ, ਜਦਕਿ apex (example.com) ਲਈ ਇੱਕ A ਰਿਕਾਰਡ, ALIAS/ANAME ਜਾਂ ਹੋਰ ਹਲ ਹੋ ਸਕਦਾ ਹੈ।
ਰਜਿਸਟਰਾਰ 'ਤੇ ਡੋਮੇਨ ਦੇ nameservers ਚੈੱਕ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਉਸ DNS ਪ੍ਰੋਵਾਈਡਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਐਡੀਟ ਕਰ ਰਹੇ ਹੋ। ਕੇਵਲ active nameservers ਹੀ authoritative ਹੁੰਦੇ ਹਨ; ਕਿਸੇ ਹੋਰ ਜਗ੍ਹਾ 'ਤੇ ਰਿਕਾਰਡ ਐਡੀਟ ਕਰਨ ਨਾਲ ਪਬਲਿਕ ਇੰਟਰਨੈਟ 'ਤੇ ਕੁਝ ਨਹੀਂ ਬਦਲੇਗਾ।
ਜੇ ਤੁਹਾਡੇ ਹੋਸਟ ਨੇ IPv4 ਪਤਾ ਦਿੱਤਾ ਹੈ ਤਾਂ A ਰਿਕਾਰਡ ਵਰਤੋ, ਜੇ IPv6 ਟਾਰਗੇਟ ਦਿੱਤਾ ਹੈ ਤਾਂ AAAA; ਜਦੋਂ ਹੋਸਟ ਤੁਹਾਨੂੰ ਹੋਰ ਹੋਸਟਨੇਮ ਦਿੰਦਾ ਹੈ ਤਾਂ CNAME ਵਰਤੋਂ (ਆਮ ਤੌਰ 'ਤੇ www ਲਈ)। TXT ਰਿਕਾਰਡ ਤਸਦੀਕ ਅਤੇ ਚੈਲੈਂਜ ਲਈ ਹੁੰਦੇ ਹਨ ਅਤੇ ਉਹ ਨਿਰਧਾਰਿਤ ਨਾਮ ਤੇ ਹੀ ਬਣਾਏ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ।
ਇੱਕ ਪੁਰਾਣਾ ਜਾਂ ਗ਼ਲਤ AAAA ਰਿਕਾਰਡ ਕੁਝ ਯੂਜ਼ਰਾਂ ਨੂੰ IPv6 ਰਾਹੀਂ ਪੁਰਾਣੇ ਸਰਵਰ ਉੱਤੇ ਭੇਜ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਹੋਰ ਲੋਕ IPv4 ਤੇ ਸਹੀ ਟਾਰਗੇਟ ਪਹੁੰਚਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ ਹੋਸਟ ਨੇ IPv6 ਨਹੀਂ ਦਿੱਤਾ, ਤਾਂ ਗ਼ਲਤ AAAA ਹਟਾਉਣਾ ਆਮ ਤੌਰ 'ਤੇ ਸੁਲਝਾਅ ਹੁੰਦਾ ਹੈ।
ਇਸ ਦਾ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਇਹ ਹੈ ਕਿ ਹੋਸਟਿੰਗ ਪਾਸੇ ਤੁਸੀਂ ਸਿਰਫ ਇੱਕ ਹੋਸਟਨੇਮ ਸੰਰਚਿਤ ਕੀਤਾ ਹੈ (ਸਿਰਫ apex ਜਾਂ ਸਿਰਫ www) ਜਾਂ ਤੁਹਾਡੇ ਕੋਲ ਮੁਕਾਬਲੇ ਵਾਲੇ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ ਹਨ ਜੋ HTTP↔HTTPS ਜਾਂ apex↔www ਵਿਚ ਵਾਪਸੀ ਕਰਵਾ ਰਹੇ ਹਨ। ਇੱਕ canonical ਹੋਸਟਨੇਮ ਚੁਣੋ, ਦੋਹਾਂ ਨਾਮਾਂ ਨੂੰ ਸੰਰਚਿਤ ਕਰੋ ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਸਾਫ ਰੀਡਾਇਰੈਕਟ ਰਾਹ ਰੱਖੋ।
ਹਾਂ। SSL ਜਾਰੀ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਦਾ ਹਰ ਥਾਂ ਤੋਂ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਟਾਰਗੇਟ ਵੱਲ ਰਿਜ਼ੋਲ ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ। DNS ਸਹੀ ਹੋਣ ਦੇ ਬਾਅਦ ਵੀ ਸਰਟੀਫਿਕੇਟ ਕੁਝ ਸਮਾਂ ਲੈ ਸਕਦਾ ਹੈ — ਇਸ ਦੌਰਾਨ ਰਿਕਾਰਡਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਬਦਲਣਾ ਜਾਰੀ ਕਰਨ ਦੇ ਸਲੇ ਲਈ ਨੁਕਸਾਨਦਾਇਕ ਹੈ।
TTL ਉਹ ਸਮਾਂ ਹੈ ਜਿਸ ਲਈ ਰਿਜ਼ੋਲਵਰ ਇੱਕ ਜਵਾਬ ਕੈਸ਼ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਤੁਸੀਂ ਰਿਕਾਰਡ ਠੀਕ ਕਰਦੇ ਹੋ, ਕੁਝ ਨੈੱਟਵਰਕ ਪੁਰਾਣੇ ਮੁੱਲ ਨੂੰ TTL ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਦਿਖਾਇਆ ਕਰਦੇ ਹਨ। ਦੋ ਵੱਖਰੇ ਨੈੱਟਵਰਕਾਂ (ਜਿਵੇਂ Wi‑Fi ਅਤੇ ਮੋਬਾਈਲ ਡੇਟਾ) ਤੋਂ ਟੈਸਟ ਕਰੋ ਅਤੇ ਹਰ ਕੁਝ ਮਿੰਟਾਂ 'ਚ DNS ਬਦਲਣ ਤੋਂ ਬਚੋ ਤਾਂ ਕਿ ਪ੍ਰੋਪਾਗੇਸ਼ਨ ਵੇਖਣ ਯੋਗ ਰਹੇ।
ਇੱਕ repeatable ਚੈਕ ਵਰਗਾ dig ਜਾਂ nslookup ਵਰਤੋਂ ਕਰਕੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ A/AAAA/CNAME/TXT ਦੇ ਜਵਾਬ ਤੁਹਾਡੇ ਉਮੀਦ ਕੀਤੇ ਟਾਰਗੇਟ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਫਿਰ apex ਅਤੇ www ਦੋਹਾਂ ਲਈ http:// ਅਤੇ https:// ਟੈਸਟ ਕਰੋ। ਜੇ ਇਕ ਨੈੱਟਵਰਕ ਦੂਜੇ ਤੋਂ ਵੱਖਰਾ ਜਵਾਬ ਦਿਖਾ ਰਿਹਾ ਹੈ ਤਾਂ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕੈਸ਼ਿੰਗ ਹੈ; ਜੇ ਸਾਰੇ ਨੈੱਟਵਰਕ ਗ਼ਲਤ ਜਵਾਬ ਦਿਖਾ ਰਹੇ ਹਨ ਤਾਂ ਇਹ ਸੰਰਚਨਾ ਦੀ ਗਲਤੀ ਹੈ।
Koder.ai 'ਤੇ, ਐਪ ਦੇ ਡੋਮੇਨ ਸੈਟਅਪ ਸਕਰੀਨ ਨੂੰ ਉਮੀਦ ਕੀਤੇ ਟਾਰਗੇਟ ਲਈ ਸੋਰਸ ਆਫ਼ ਟਰੂਥ ਮੰਨੋ। ਫਿਰ ਉਕਤ ਟਾਰਗੇਟ ਨੂੰ authoritative DNS ਪ੍ਰੋਵਾਈਡਰ ਵਿੱਚ ਠੀਕ ਢੰਗ ਨਾਲ ਮਿਲਾਓ। DNS ਬਦਲਣ ਤੋਂ ਬਾਅਦ SSL ਦੀ ਸਥਿਤੀ ਚੈੱਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਥੋੜਾ ਸਮਾਂ ਦਿਓ ਅਤੇ ਜੇ ਰੂਟਿੰਗ ਬਦਲ ਰਹੀ ਹੈ ਤਾਂ ਸਨੈਪਸ਼ਾਟ/ਰੋਲਬੈਕ ਦੀ ਵਰਤੋਂ ਕਰੋ ਤਾਂ ਜੋ ਜਲਦੀ ਪਹਿਲੀ-ਅਚੰਗੀ ਸਥਿਤੀ ਨੂੰ ਵਾਪਸ ਲਿਆ ਜਾ ਸਕੇ।