CDN ತನ್ನ ವಿಳಾಸಗಳನ್ನು ಬದಲಿಸಿದಾಗ VPN ಡೊಮೇನ್ ನಿಯಮ ಮುರಿಯುತ್ತದೆ

ಒಂದು ಹುಡುಕಾಟದಿಂದ ವಿಳಾಸವನ್ನು ನಿಮ್ಮ ರೂಟಿಂಗ್ ನಿಯಮಕ್ಕೆ ನಕಲಿಸುತ್ತೀರಿ, ಸೈಟ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಒಂದು ವಾರದ ನಂತರ ಮಾಡುವುದಿಲ್ಲ. ನಿಯಮದಲ್ಲಿ ಏನೂ ಬದಲಾಗಿಲ್ಲ. ಸೇವೆ ಬೇರೆ ಎಡ್ಜ್ ವಿಳಾಸಕ್ಕೆ ಸ್ಥಳಾಂತರಗೊಂಡಿತು, ಕ್ಲೈಂಟ್ ಬೇರೆ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಪರಿಹರಿಸಿತು, ಅಥವಾ ಸೆಷನ್ IPv6 ಗೆ ಬದಲಾಯಿತು. ನಿಮ್ಮ ಮುಂದಿರುವ ನಿರ್ಧಾರ ಹೆಸರು ಆಧಾರಿತ ನಿಯಮ ಅಥವಾ ಸ್ಪಷ್ಟ ಶ್ರೇಣಿ ಈ ಸೇವೆಗೆ ಸರಿಯಾದ ಸಾಧನವೇ ಎಂಬುದು, ಮತ್ತು ಮೂರು ಷರತ್ತುಗಳು ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. ಮುಂದಿನದು ಹೆಸರನ್ನು ವಿಳಾಸದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಸ್ಥಿರವಾಗಿದೆ.

ಒಂದು ಹುಡುಕಾಟ ದಾಸ್ತಾನು ಏಕೆ ಅಲ್ಲ

ವಿಷಯ ವಿತರಣಾ ಜಾಲವು ಪರಿಹಾರಕ, ಪ್ರದೇಶ ಮತ್ತು ಕ್ಷಣಕ್ಕೆ ಆಯ್ಕೆಮಾಡಿದ ವಿಳಾಸದೊಂದಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಬೇರೆ ಬೇರೆ ಜಾಲಗಳಿಂದ ಎರಡು ಬಾರಿ ಕೇಳಿ, ನೀವು ಬೇರೆ ಉತ್ತರಗಳನ್ನು ಪಡೆಯಬಹುದು. ಒಮ್ಮೆ ಕೇಳಿ ಉತ್ತರವನ್ನು ಸೇವೆಯ ವಿಳಾಸ ಪಟ್ಟಿ ಎಂದು ಪರಿಗಣಿಸಿ, ನೀವು ಬರೆಯುವ ನಿಯಮ ನಿಯಮವಲ್ಲ, ಸ್ನ್ಯಾಪ್ಶಾಟ್ ಆಗುತ್ತದೆ. DNS ಉತ್ತರವನ್ನು ಸಂರಚನೆ ಎಂದು ಪರಿಗಣಿಸುವ ಸಂಪೂರ್ಣ ಸಮಸ್ಯೆ ಅದೇ.

ಎರಡನೇ ಅಂತರವಿದೆ. ಒಂದು ಗೋಚರ ಹೋಸ್ಟ್ ಹೆಸರು ಇಡೀ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ವಿರಳವಾಗಿ ಆವರಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಲಾಗಿನ್, ಮೀಡಿಯಾ ಮತ್ತು API ಸಂಚಾರ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರತ್ಯೇಕ ಹೆಸರುಗಳನ್ನು ಬಳಸುತ್ತವೆ. ವಿಳಾಸ ಪಟ್ಟಿಯ ಹೋಸ್ಟ್ ಹೆಸರಿನಿಂದ ನಿರ್ಮಿಸಿದ ನಿಯಮ ಪುಟವನ್ನು ಆವರಿಸಿ ವೀಡಿಯೊವನ್ನು ತಪ್ಪಿಸಬಹುದು, ಅದನ್ನು ರೂಟಿಂಗ್ ದೋಷವಲ್ಲ, ಭಾಗಶಃ ವೈಫಲ್ಯ ಎಂದು ಓದಲಾಗುತ್ತದೆ.

ಮೂರನೇ ಅಂತರ ವಿಳಾಸ ಕುಟುಂಬ. ಕೇವಲ v4 ಗಾಗಿ ನಿಯಮವು ಕ್ಲೈಂಟ್ ಆದ್ಯತೆ ನೀಡಬಹುದಾದ AAAA ದಾಖಲೆಯ ಬಗ್ಗೆ ಏನೂ ಹೇಳುವುದಿಲ್ಲ.

ಡೊಮೇನ್ ನಿಯಮ ಅಥವಾ ಶ್ರೇಣಿಗಳನ್ನು ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು

ಮೊದಲನೆಯದಾಗಿ, ಸೇವೆಯು ನೀವು ಹೊಂದಿ ದಾಖಲಿಸಬಹುದಾದ ಸ್ಥಿರ ಪೂರ್ವಪ್ರತ್ಯಯಗಳ ಗುಂಪನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆಯೇ? ಹೌದಾದರೆ, ಸ್ಪಷ್ಟ ಶ್ರೇಣಿಗಳು ಪ್ರಾಮಾಣಿಕ ಮತ್ತು ಅಗ್ಗ. ಇಲ್ಲದಿದ್ದರೆ, ಡೊಮೇನ್ ನಿಯಮವೇ ಸೇವೆಯನ್ನು ಅನುಸರಿಸಬಲ್ಲ ಏಕೈಕ ಕಾರ್ಯವಿಧಾನ.

ಎರಡನೆಯದಾಗಿ, ನಿಮ್ಮ ಕ್ಲೈಂಟ್ನ ಡೊಮೇನ್ ಕಾರ್ಯವಿಧಾನ ರಿಫ್ರೆಶ್ ಆಗುತ್ತದೆಯೇ? ಸಂಪರ್ಕದ ಸಮಯದಲ್ಲಿ ಒಮ್ಮೆ ಪರಿಹರಿಸಿ ಮತ್ತೆಂದೂ ಆಗದ ನಿಯಮ ಉತ್ತಮ ಬ್ರಾಂಡಿಂಗ್ನ ಸ್ನ್ಯಾಪ್ಶಾಟ್. ಮೂರನೆಯದಾಗಿ, ಕಾರ್ಯವಿಧಾನವು ಉಪಡೊಮೇನ್ಗಳು ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಆವರಿಸುತ್ತದೆಯೇ, ಅಥವಾ ನೀವು ಟೈಪ್ ಮಾಡಿದ ಹೆಸರುಗಳನ್ನು ಮಾತ್ರವೇ?

ಆ ಮೂರಕ್ಕೆ ಉತ್ತರಿಸಿ, ಆಯ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಪಷ್ಟವಾಗಿರುತ್ತದೆ. ಊಹೆ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಉತ್ಪಾದನೆಯಲ್ಲಿ ವಿಫಲವಾಗುವ ನಿಯಮವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಸೆಷನ್ ಪರೀಕ್ಷಿಸಿ, ಪುಟವಲ್ಲ

ಪುಟವನ್ನು ಲೋಡ್ ಮಾಡಿ, ನಂತರ ಮುಖ್ಯ ಕ್ರಿಯೆಯನ್ನು ಮಾಡಿ: ಸೈನ್ ಇನ್ ಮಾಡಿ, ಪ್ಲೇಬ್ಯಾಕ್ ಪ್ರಾರಂಭಿಸಿ, ಫೈಲ್ ಅಪ್ಲೋಡ್ ಮಾಡಿ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಹೋಸ್ಟ್ ತಲುಪಬಹುದು, ಮತ್ತು ವಿಫಲವಾಗುವುದು ನಿಮ್ಮ ನಿಯಮ ತಪ್ಪಿಸಿದ್ದು.

ಪುಟ ತೋರಿಸುವುದನ್ನು ಅಲ್ಲ, ಸೆಷನ್ ನಿಜವಾಗಿ ಯಾವುದರೊಂದಿಗೆ ಸಂಪರ್ಕಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಪಟ್ಟಿ ಮಾಡಿ:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

ಹೋಲಿಕೆಯ ಸಮಯದಲ್ಲಿ ಪರಿಹಾರಕವನ್ನು ಗೋಚರವಾಗಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಒಂದು ಪರಿಹಾರಕದಿಂದ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಿಂದ ವಿಫಲವಾಗುವ ನಿಯಮ ನಿಮಗೆ CDN ಉತ್ತರದ ಬಗ್ಗೆ ಹೇಳುತ್ತದೆ, ಸುರಂಗದ ಬಗ್ಗೆ ಅಲ್ಲ. ಸಣ್ಣ TTL ಎಂದರೆ ನೀವು ದಾಖಲಿಸಿದ ಉತ್ತರಕ್ಕೆ ಅವಧಿ ಇದೆ ಎಂದೂ ಅರ್ಥ.

ಪ್ರತಿ ಕಾರ್ಯವಿಧಾನ ನಿಜವಾಗಿ ಏನನ್ನು ಆವರಿಸುತ್ತದೆ

ಎರಡೂ ಕಾರ್ಯವಿಧಾನಗಳು ಸೆಟ್ಟಿಂಗ್ಸ್ ಪುಟದಲ್ಲಿ ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ಒಳಗೆ ಬೇರೆ ರೀತಿ ವರ್ತಿಸುತ್ತವೆ.

ಕರ್ನಲ್ ವಿಳಾಸ ಮಾರ್ಗ ಪೂರ್ವಪ್ರತ್ಯಯಗಳನ್ನು ಹೊಂದಿಸುತ್ತದೆ. ಹೋಸ್ಟ್ ಹೆಸರು ಏನೆಂದು ಅದಕ್ಕೆ ಗೊತ್ತಿಲ್ಲ, ಆದ್ದರಿಂದ ವಿಳಾಸ ಬದಲಿಸುವ ಸೇವೆಯನ್ನು ಅನುಸರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಡೊಮೇನ್ ನಿಯಮ ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಿ ಫಲಿತಾಂಶವನ್ನು ರೂಟ್ ಮಾಡುತ್ತದೆ; ಅದು ಸೇವೆಯನ್ನು ಅನುಸರಿಸುತ್ತದೆ ಆದರೆ ಪರಿಹಾರಕ, ರಿಫ್ರೆಶ್ ವರ್ತನೆ ಮತ್ತು ಉಪಡೊಮೇನ್ಗಳ ಬಗ್ಗೆ ಕ್ಲೈಂಟ್ನ ನಿರ್ವಹಣೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ ಹೆಸರುಗಳನ್ನು ಅನುಸರಿಸುವ ನಿಯಮವನ್ನು ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಬಳಸುವ ಪರಿಹಾರಕದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಬೇಕು.

ಯಾವುದೂ ಇನ್ನೊಂದರ ಸೂಪರ್ಸೆಟ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಟಿಪ್ಪಣಿ ಇಲ್ಲದೆ ಅವುಗಳನ್ನು ಮಿಶ್ರಣ ಮಾಡುವುದು ನಂತರ ಗೊಂದಲ ಉಂಟುಮಾಡುತ್ತದೆ.

ಸೇವೆ ಬದಲಾದ ನಂತರ ಮತ್ತೆ ಪರಿಶೀಲಿಸಿ

ಕ್ಲೈಂಟ್ ನವೀಕರಣ ಅಥವಾ ಸೇವೆ ಬದಲಾವಣೆಯ ನಂತರ ಅದೇ ಸೆಷನ್ ಪರೀಕ್ಷೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಮೊದಲು ಕೆಲಸ ಮಾಡಿದ ವಿಳಾಸ ಪಟ್ಟಿ ಆ ಅವಧಿಯ ಪುರಾವೆ, ಸೇವೆಯ ಮೂಲಸೌಕರ್ಯದ ಶಾಶ್ವತ ದಾಸ್ತಾನು ಅಲ್ಲ.

ಯಾವ ಕಾರ್ಯವಿಧಾನ ಯಾವ ಹೋಸ್ಟ್ ಹೆಸರನ್ನು ಆವರಿಸುತ್ತದೆ ಮತ್ತು ಕೊನೆಯ ಪರಿಶೀಲನೆಯ ದಿನಾಂಕವನ್ನು ಬರೆಯಿರಿ.

ಆ ಟಿಪ್ಪಣಿಯೇ ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ನಿಯಮ ಮತ್ತು ಯಾರೂ ಮುಟ್ಟಲು ಧೈರ್ಯ ಮಾಡದ ನಿಯಮದ ನಡುವಿನ ವ್ಯತ್ಯಾಸ. ಸೇವೆ ತನ್ನದೇ ಪೂರ್ವಪ್ರತ್ಯಯ ಪಟ್ಟಿಯನ್ನು ಪ್ರಕಟಿಸಿದರೆ, ಅದನ್ನು ಬಳಸಿ ದಿನಾಂಕ ಉಲ್ಲೇಖಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ, ಹಾಗೆ ಹೇಳಿ, ಮತ್ತು ಡೊಮೇನ್ ನಿಯಮವನ್ನು ಅದರ ರಿಫ್ರೆಶ್ ವರ್ತನೆಯೊಂದಿಗೆ ಪಕ್ಕದಲ್ಲಿ ಬರೆದಿಡಿ.