ਕਿਉਂ ਇੱਕ ਨਿੱਜੀ Route 53 ਜ਼ੋਨ ਜਨਤਕ ਨਾਵਾਂ ਲਈ NXDOMAIN ਭੇਜਦਾ ਹੈ

ਨਿੱਜੀ Route 53 ਜ਼ੋਨ ਜਨਤਕ ਰਿਕਾਰਡ ਨਾਲ ਜੁੜਨ ਦੀ ਬਜਾਏ ਨਾਮ ਦਾ ਜਵਾਬ ਬਦਲ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਕਰਕੇ ਲੋਕਾਂ ਨੂੰ ਸਭ ਤੋਂ ਮਾੜੇ ਪਲ ਵਿੱਚ ਹੈਰਾਨੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਅੰਦਰੂਨੀ ਰਿਕਾਰਡ ਸ਼ਾਮਲ ਕਰੋ api.example.net ਲਈ ਨਿੱਜੀ ਜ਼ੋਨ ਵਿੱਚ example.net, ਇਸਨੂੰ VPC ਨਾਲ ਜੋੜੋ, ਅਤੇ ਉਸ ਮੁੱਢਲੇ ਨਾਮ ਹੇਠਾਂ ਹਰ ਹੋਰ ਨਾਮ ਹੁਣ ਸਿਰਫ਼ ਨਿੱਜੀ ਜ਼ੋਨ ਤੋਂ ਹੀ ਜਵਾਬ ਪਾਉਂਦਾ ਹੈ। ਜਿਹੜਾ ਕਲਾਇੰਟ ਕੱਲ੍ਹ www.example.net ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਸੀ, ਉਸਨੂੰ ਅੱਜ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਮਿਲਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਸਮੀਖਿਆ ਉਸੇ ਅਸਫਲ ਕੁਐਰੀ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਜ਼ੋਨ ਵੱਲ ਬਾਹਰ ਜਾਂਦੀ ਹੈ।

ਕੰਸੋਲ ਤੋਂ ਨਹੀਂ, ਕੁਐਰੀ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

ਦੂਜਾ ਕਮਾਂਡ ਹੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸ ਦੀ ਸਥਿਤੀ ਲਾਈਨ ਅਤੇ authority ਭਾਗ ਉਸ ਜ਼ੋਨ ਦਾ ਨਾਮ ਦਿੰਦੇ ਹਨ ਜਿਸਨੇ ਜਵਾਬ ਬਣਾਇਆ, ਇਸ ਲਈ ਤੁਸੀਂ ਨਿੱਜੀ ਜ਼ੋਨ ਤੋਂ ਆਏ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਨੂੰ ਟਾਈਮਆਊਟ, ਬਲਾਕ ਕੀਤੇ ਪੋਰਟ ਜਾਂ ਕੁਐਰੀ ਕਦੇ ਨਾ ਮਿਲੇ resolver ਤੋਂ ਵੱਖ ਕਰ ਸਕਦੇ ਹੋ। resolvectl ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਉੱਪਰਲੇ ਸਰਵਰ ਨੂੰ ਪੁੱਛਿਆ ਗਿਆ, ਅਤੇ ਇਹ ਅਕਸਰ ਉਹ resolver ਨਹੀਂ ਹੁੰਦਾ ਜੋ ਤੁਸੀਂ ਮੰਨਿਆ ਸੀ ਕਿ VPN ਨੇ ਭੇਜਿਆ ਹੈ।

ਜੇ ਟਰੇਸ ਕੀਤੀ ਕੁਐਰੀ ਜਨਤਕ ਪਤਾ ਭੇਜਦੀ ਹੈ ਅਤੇ ਆਮ ਕੁਐਰੀ ਨਹੀਂ, ਤਾਂ ਜਨਤਕ ਰਿਕਾਰਡ ਸਹੀ-ਸਲਾਮਤ ਹੈ ਅਤੇ ਜਵਾਬ ਨਿੱਜੀ ਦ੍ਰਿਸ਼ ਦੇ ਰਿਹਾ ਹੈ। ਇਹੀ ਇੱਕ ਤੁਲਨਾ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਇਸ ਪੰਨੇ ਦੇ ਬਾਕੀ ਹਿੱਸੇ ਦਾ ਕਿਹੜਾ ਅੱਧਾ ਤੁਹਾਡੇ ਲਈ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਪੜ੍ਹੋ ਕਿ ਕਿਹੜੇ ਜ਼ੋਨ ਨੇ ਜਵਾਬ ਦਿੱਤਾ

ਹੇਠ ਲਿਖਿਆ ਲੈ ਕੇ ਆਉਣ ਵਾਲਾ ਜਵਾਬ: NXDOMAIN ਅਤੇ authority ਭਾਗ ਵਿੱਚ ਨਿੱਜੀ ਜ਼ੋਨ ਦਾ SOA ਹੋਵੇ, ਤਾਂ ਉਹ ਉਸ ਜ਼ੋਨ ਦਾ ਅੰਤਿਮ ਜਵਾਬ ਹੈ, ਅਸਫਲ ਖੋਜ ਨਹੀਂ। Route 53 Resolver ਨੇ ਨਿੱਜੀ ਹੋਸਟਡ ਜ਼ੋਨ ਚੁਣਿਆ ਕਿਉਂਕਿ ਨਾਮ ਮੇਲ ਖਾਂਦਾ ਸੀ, ਫਿਰ ਮੰਗੀ ਕਿਸਮ ਦਾ ਰਿਕਾਰਡ ਨਹੀਂ ਮਿਲਿਆ, ਅਤੇ ਦਰਜ ਵਿਵਹਾਰ ਇਹ ਹੈ ਕਿ ਸਵਾਲ ਜਨਤਕ DNS ਨੂੰ ਭੇਜਣ ਦੀ ਬਜਾਏ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਵਾਪਸ ਕੀਤਾ ਜਾਵੇ।

ਚੋਣ ਵਿਸ਼ਿਸ਼ਟਤਾ ਦੀ ਪੈਰਵੀ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਕਈ ਨਿੱਜੀ ਨਾਮ-ਥਾਂਵਾਂ ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਚੜ੍ਹਦੀਆਂ ਹਨ, ਸਭ ਤੋਂ ਵਿਸ਼ਿਸ਼ਟ ਮੇਲ ਖਾਂਦਾ ਜ਼ੋਨ ਜਿੱਤਦਾ ਹੈ, ਅਤੇ ਚੁਣੇ ਗਏ ਉਪ-ਜ਼ੋਨ ਵਿੱਚ ਨਾ ਹੋਣ ਵਾਲੇ ਨਾਮ ਲਈ ਵੱਡਾ ਨਿੱਜੀ ਮੁੱਢਲਾ ਨਾਮ ਦੂਜਾ ਮੌਕਾ ਨਹੀਂ ਪਾਉਂਦਾ। ਫਾਰਵਰਡਿੰਗ ਨਿਯਮ ਇੱਕ ਹੋਰ ਪਰਤ ਜੋੜਦੇ ਹਨ, ਕਿਉਂਕਿ ਡੋਮੇਨ-ਖਾਸ Resolver ਨਿਯਮ ਨਿੱਜੀ ਹੋਸਟਡ ਜ਼ੋਨ ਦੇ ਸੰਬੰਧ ਨੂੰ ਹਰਾ ਸਕਦਾ ਹੈ। ਇਹ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਜ਼ੋਨ ਖਾਲੀ ਹੈ, ਸੰਬੰਧ ਅਤੇ ਨਿਯਮ ਗਿਣੋ।

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

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

ਨਿੱਜੀ ਜ਼ੋਨ ਕਿਉਂ ਜਿੱਤਦਾ ਹੈ

ਸੰਬੰਧ ਹੀ ਜ਼ੋਨ ਨੂੰ VPC ਲਈ ਦਿਖਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਸ VPC ਦਾ resolver ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਜਿਸ VPC ਤੋਂ ਕਲਾਇੰਟ ਦਾ ਟ੍ਰੈਫਿਕ ਆਉਂਦਾ ਹੈ ਉਸ ਨਾਲ ਜੁੜਿਆ ਨਾ ਹੋਣ ਵਾਲਾ ਨਿੱਜੀ ਜ਼ੋਨ ਬਿਲਕੁਲ ਪ੍ਰਭਾਵ ਨਹੀਂ ਪਾਉਂਦਾ, ਜਦੋਂ ਕਿ ਗਲਤ VPC ਨਾਲ ਸੰਬੰਧ ਗਲਤ ਆਬਾਦੀ ਲਈ ਨਿੱਜੀ ਜਵਾਬ ਬਣਾਉਂਦਾ ਹੈ। ਰਿਕਾਰਡ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਸੰਬੰਧਾਂ ਦੀ ਸੂਚੀ ਵੇਖੋ, ਕਿਉਂਕਿ ਜ਼ੋਨ ਸਹੀ ਹੋ ਕੇ ਵੀ ਅਦਿੱਖ ਰਹਿ ਸਕਦਾ ਹੈ।

ਇੱਕ ਦੂਜੇ ਉੱਤੇ ਚੜ੍ਹਦੀਆਂ ਨਾਮ-ਥਾਂਵਾਂ ਉਲਝਣ ਦਾ ਦੂਜਾ ਸਰੋਤ ਹਨ। example.net ਲਈ ਨਿੱਜੀ ਜ਼ੋਨ ਅਤੇ api.example.net ਲਈ ਨਿੱਜੀ ਜ਼ੋਨ ਦੋਵੇਂ API ਕੁਐਰੀ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ, ਅਤੇ ਵਧੇਰੇ ਵਿਸ਼ਿਸ਼ਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਤਦ ਲਾਭਦਾਇਕ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਤੰਗ ਅੰਦਰੂਨੀ ਨਾਮ-ਥਾਂ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਤਦ ਖਤਰਨਾਕ ਹੈ ਜਦੋਂ ਤੰਗ ਜ਼ੋਨ ਵਿੱਚ ਵੱਡੇ ਜ਼ੋਨ ਵਾਲਾ ਰਿਕਾਰਡ ਨਹੀਂ ਹੈ। ਨਿੱਜੀ ਹੋਸਟਡ ਜ਼ੋਨਾਂ ਬਾਰੇ ਵਿਚਾਰ Route 53 ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਹੇਠਾਂ ਡਿੱਗਣ ਦਾ ਵਿਵਹਾਰ ਅਤੇ ਨਿਯਮਾਂ ਦੀ ਤਰਜੀਹ ਦੋਵੇਂ ਦੱਸਦੇ ਹਨ, ਅਤੇ ਦੂਜਾ ਉੱਪਰ ਚੜ੍ਹਦਾ ਜ਼ੋਨ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਪੜ੍ਹਨੇ ਚਾਹੀਦੇ ਹਨ।

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

ਰਿਕਾਰਡ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਨਾਮ-ਥਾਂ ਚੁਣੋ

ਜੇ ਸਿਰਫ਼ ਅੰਦਰੂਨੀ ਸੇਵਾਵਾਂ ਦੇ ਨਵੇਂ ਪਰਿਵਾਰ ਨੂੰ ਨਿੱਜੀ ਨਾਮ ਚਾਹੀਦੇ ਹਨ, ਤਾਂ ਉਸਨੂੰ ਸਮਰਪਿਤ ਨਿੱਜੀ ਸਬਡੋਮੇਨ ਦਿਓ ਅਤੇ ਜਨਤਕ ਮੁੱਢਲੇ ਨਾਮ ਨੂੰ ਛੇੜੋ ਨਾ। internal.example.net ਵਰਗਾ ਨਾਮ www.example.net ਨੂੰ ਛਾਂ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਅਤੇ ਗੁੰਮ ਰਿਕਾਰਡ ਦਾ ਪ੍ਰਭਾਵ ਘੇਰਾ ਉਹਨਾਂ ਨਾਵਾਂ ਤੱਕ ਸੀਮਤ ਹੈ ਜੋ ਤੁਸੀਂ ਇਸ ਮਕਸਦ ਲਈ ਬਣਾਏ ਸਨ। ਕੀਮਤ ਇਹ ਹੈ ਕਿ ਮੌਜੂਦਾ URL ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਨਵੇਂ ਨਾਮ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾ ਸਕਦੇ।

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

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

resolver ਦਾ ਰਾਹ, ਫਿਰ ਰੂਟ ਟਰੇਸ ਕਰੋ

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

ਨਾਮ ਹੱਲ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਵਾਪਸ ਮਿਲੇ ਪਤੇ ਤੱਕ ਦਾ ਰਾਹ ਵੱਖਰੇ ਕਦਮ ਵਜੋਂ ਜਾਂਚੋ, ਉਦਾਹਰਨ ਲਈ ip route get ਨਾਲ ਕੁਐਰੀ ਵੱਲੋਂ ਵਾਪਸ ਕੀਤੇ ਪਤੇ ਦੇ ਵਿਰੁੱਧ। ਪਤੇ ਤੱਕ ਰੂਟ ਤੋਂ ਬਿਨਾਂ ਸਹੀ ਨਿੱਜੀ ਜਵਾਬ ਰੂਟਿੰਗ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਰਿਕਾਰਡ ਨਾ ਹੋਣ ਦਾ ਜਵਾਬ DNS ਦ੍ਰਿਸ਼ ਦੀ ਸਮੱਸਿਆ ਹੈ; ਦੋਵਾਂ ਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਮੰਨਣ ਨਾਲ ਅਜਿਹੇ ਸੁਧਾਰ ਬਣਦੇ ਹਨ ਜੋ ਟਿਕਦੇ ਨਹੀਂ। ਸੇਵਾ ਦੇ TLS ਹੋਸਟਨਾਮ ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਜਾਂਚਾਂ ਨੂੰ ਬਿਨਾਂ ਬਦਲੇ ਰੱਖੋ, ਕਿਉਂਕਿ ਨਿੱਜੀ ਪਤਾ ਬਦਲਦਾ ਹੈ ਕਿ ਕਨੈਕਸ਼ਨ ਕਿੱਥੇ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਿਹੜਾ ਸਰਟੀਫਿਕੇਟ ਵੈਧ ਹੈ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ।

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