ಖಾಸಗಿ 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 ಯಾವ ಮೇಲ್ಭಾಗದ ಸರ್ವರ್‌ಗೆ ಕೇಳಲಾಯಿತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಹಲವು ಬಾರಿ VPN ಕಳುಹಿಸಿದೆ ಎಂದು ನೀವು ಊಹಿಸಿದ resolver ಅಲ್ಲ.

ಟ್ರೇಸ್ ಮಾಡಿದ ಪ್ರಶ್ನೆ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು ಹಿಂತಿರುಗಿಸಿ ಸಾಮಾನ್ಯ ಪ್ರಶ್ನೆ ಹಿಂತಿರುಗಿಸದಿದ್ದರೆ, ಸಾರ್ವಜನಿಕ ದಾಖಲೆ ಅಖಂಡವಾಗಿದೆ ಮತ್ತು ಉತ್ತರ ನೀಡುತ್ತಿರುವುದು ಖಾಸಗಿ ನೋಟ. ಆ ಒಂದೇ ಹೋಲಿಕೆ ಈ ಪುಟದ ಉಳಿದ ಭಾಗದ ಯಾವ ಅರ್ಧ ನಿಮಗೆ ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ಯಾವ ವಲಯ ಉತ್ತರಿಸಿತು ಎಂದು ಓದಿ

ಈ ಕೆಳಗಿನದನ್ನು ಒಳಗೊಂಡ ಉತ್ತರ: 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]"

ಎರಡೂ ಆಜ್ಞೆಗಳಿಗೆ ವಲಯವನ್ನು ಹೊಂದಿರುವ ಖಾತೆಯ ರುಜುವಾತುಗಳು ಬೇಕು, ಮತ್ತು ಎರಡನೆಯದಕ್ಕೆ ಮೊದಲನೆಯದರಿಂದ ವಲಯ ID ಬೇಕು. ಅದನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ID ಯಿಂದ ಬದಲಾಯಿಸಿ; ಮೇಲಿನ ಪ್ಲೇಸ್‌ಹೋಲ್ಡರ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿಜವಲ್ಲ.

ಖಾಸಗಿ ವಲಯ ಏಕೆ ಗೆಲ್ಲುತ್ತದೆ

ವಲಯವನ್ನು 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 ಮತ್ತು ನೀವು ಪರಿಶೀಲಿಸಿದ ಹೆಸರುಗಳನ್ನು ಬರೆದು ಮುಗಿಸಿ. ಆಗ ಮುಂದಿನ ಬಾರಿ ದಾಖಲೆ ಸೇರಿಸುವವರಿಗೆ ಆ ಕ್ಲೈಂಟ್ ಜನಸಂಖ್ಯೆಗೆ ಯಾವ ಹೆಸರಿನ ಸ್ಥಳ ಅಧಿಕೃತ ಎಂದು ತಿಳಿಯುತ್ತದೆ.