aws-rds-readreplica-general_log

https://www.facebook.com/groups/awskrug/permalink/2404835746285102/

다음과 같은 질문이 올라왔다.
바로 생각난건 general_log.. 그래서 Master와 Readreplica 가 각각 다른 Parameter Group(이하 PG)를 가질수 있는지 확인해보기로 했다.

먼저 Readreplica 생성했다.

실제로 읽기복제본을 만들때는 파라메터 그룹을 수정할수 없다.

Master 의 PG를 그대로 사용한다.

이렇게 모두 생성된 Readreplica 를 수정을 눌러보면

데이터베이스 옵션에서 파라메터 그룹을 볼수있다.
그래서 나는 따로 PG를 만들어주고..general_log 도 켜줬다.

dynamic / static 으로 나뉘는데 적용유형이 dynamic이면 PG가 적용된상태에서 라이브로 적용된다. 디비의 재시작이 필요없다.

물론..PG를 변경하게 되면 RDS의 재시작이 필요하다.

그럼 1차 결론으로 마스터와 슬레이브는 생성시엔 같은 PG를 사용한다. PG는 마스터와 슬레이브는 다르게 사용하려면 수정해야한다.

현재구성은 마스터는 general_log를 사용하지 않고, 슬레이브만 사용한다. 그럼 슬레이브에서 제네럴 로그를 쌓는지 확인해 보자.

이상하게 적용이 안되서 보니..

보류중이면 말하지;

재시작 시켜서 적용해주고~

잘쌓인다..타임존이 이상하네? 그건 넘어가고..

마스터는 안쌓이는거 확인했고~

질문의 답은 확인할수 없지만..general_log 가 마스터와 슬레이브가 별개로 쌓이는 설정이 가능하고 슬레이브의 용량이 서비스에 영향을 미칠수있다.

정도로 결론 내리겠다.

급한 테스트였지만 결론을 내린다!

aws-sns-kms-cmk

aws 관리형키를 사용할 경우 sns 암호화를 하면 cloudwatch 에서 호출이 안된다….

작업 arn:aws:sns:ap-northeast-2:userid:sns_topic을(를) 실행하지 못했습니다. 수신 오류: ‘null (Service: AWSKMS; Status Code: 400; Error Code: AccessDeniedException; Request ID: 60c4ef-f3bb-4c89-98c8-67317fc18a)’

이런 에러가 발생한다. 이경우 CMK 를 이용해서 SNS 암호화를 해야한다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/cloudwatch-receive-sns-for-alarm-trigger/

다음 링크를 참조했다.

위와 같은 구성으로 생성하고 정책을 적용한다.

{
“Version”: “2012-10-17”,
“Id”: “EMR-System-KeyPolicy”,
“Statement”: [
{
“Sid”: “Allow access for Root User”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::userid:root”
},
“Action”: “kms:*”,
“Resource”: “*”
},
{
“Sid”: “Allow access for Key Administrator”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::userid:root”
},
“Action”: [
“kms:Create*”,
“kms:Describe*”,
“kms:Enable*”,
“kms:List*”,
“kms:Put*”,
“kms:Update*”,
“kms:Revoke*”,
“kms:Disable*”,
“kms:Get*”,
“kms:Delete*”,
“kms:TagResource”,
“kms:UntagResource”,
“kms:ScheduleKeyDeletion”,
“kms:CancelKeyDeletion”
],
“Resource”: “*”
},
{
“Sid”: “Allow access for Key User (SNS IAM User)”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::userid:root”
},
“Action”: [
“kms:GenerateDataKey*”,
“kms:Decrypt”
],
“Resource”: “*”
},
{
“Sid”: “Allow access for Key User (SNS Service Principal)”,
“Effect”: “Allow”,
“Principal”: {
“Service”: [
“sns.amazonaws.com”,
“cloudwatch.amazonaws.com”
]
},
“Action”: [
“kms:GenerateDataKey*”,
“kms:Decrypt”
],
“Resource”: “*”
}
]
}

userid 부분만 수정해주면 잘작동한다.

aws-s3-delete-mfa-enable

오늘은 s3 delete 를 mfa 로 제한하는 방법에 대해서 포스팅 해보겠다.

aws 에서 s3 버킷에 대한 삭제 제한을 해야 할때가 있다.

이경우에 root access key를 생성하여야 한다.

iam 대시보드에서 mfa 와 루트 엑세스키를 생성할수 있다.

보안자격증명 관리로 이동해서 진행한다. 과정은 간단하고 쉬우니 URL을 참고하자.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_mfa.html – MFA 활성화

https://docs.aws.amazon.com/ko_kr/general/latest/gr/managing-aws-access-keys.html -access key 생성

생성한 키로 aws cli 를 사용가능하도록 설정한다

/root/.aws/credentials 다음 위치다.

access key를 넣고 mfa 를 확인해보자

root@ip-10-0-0-12 ~]# aws iam list-virtual-mfa-devices
An error occurred (AccessDenied) when calling the ListVirtualMFADevices operation: User: arn:aws:sts:: usernumber :assumed-role/AmazonEC2RoleForSSM/i-052ebb4fb1eade551 is not authorized to perform: iam:ListVirtualMFADevices on resource: arn:aws:iam:: usernumber :mfa/

루트권한이 아닐경우 위와같은 에러가 난다 administrator 계정일경우 ListVirtualMFADevices 정책이 부여되어있어 에러가 발생하지 않을것이다. 하지만 mfa는 사용할수 없을것이라 root key여야 한다.

명령어가 정상적으로 작동하면 아래와 같이 반환된다.

{
“VirtualMFADevices”: [
{
“SerialNumber”: “arn:aws:iam:: usernumber :mfa/root-account-mfa-device”,
“EnableDate”: “2019-10-28T01:06:07Z”,
“User”: {
“PasswordLastUsed”: “2020-03-18T00:27:36Z”,
“CreateDate”: “2019-07-29T13:23:03Z”,
“UserId”: “1”,
“Arn”: “arn:aws:iam:: usernumber :root”
}
}
]
}

나는 root 계정에만 mfa 를 활성화 하였기에 루트 계정에서 사용하는 mfa 만 뜬것이다.

root@ip-10-0-0-12 ~]# aws s3api put-bucket-versioning –bucket linuxer-data –versioning-configuration Status=Enabled,MFADelete=Enabled –mfa “arn:aws:iam::usernumber:mfa/root-account-mfa-device <016432>”
An error occurred (InvalidRequest) when calling the PutBucketVersioning operation: DevPay and Mfa are mutually exclusive authorization methods.

linuxer-data 라는 버킷을 versioning 을 켜고 MFADelete 를 활성화 한다는 명령어인데 에러가 발생한것이다. 이때 root 계정이 아니라서 발생한 에러이다.

root@ip-10-0-0-12 ~]# aws s3api put-bucket-versioning –bucket linuxer-data –versioning-configuration Status=Enabled,MFADelete=Enabled –mfa “arn:aws:iam:: usernumber:mfa/root-account-mfa-device 926220”

정상적으로 root access key일 경우에는 그냥 명령어가 떨어진다.

root@ip-10-0-0-12 ~]# aws s3api get-bucket-versioning –bucket linuxer-data
{
“Status”: “Enabled”,
“MFADelete”: “Enabled”
}

이후에 다음과 같이 aws s3api get-bucket-versioning –bucket linuxer-data 명령어로 정상적으로 설정이 됬는지 확인이 가능하다.

AWS-EBS-encrypt

EBS 암호화 과정을 포스팅 하겠다.

일반적으로 EBS는 기본이 암호화를 하지 않도록 설정되어있다. 이미 생성된 볼륨을 암호화 할 순 없다.

따라서 이미 생성된 인스턴스에 연결된 EBS를 암호화 하기위해선 다음과 같은 과정을 거쳐야 한다.

인스턴스종료-스냅샷-EBS 암호화로 볼륨 생성-인스턴스에서 볼륨분리-암호화된 볼륨 연결-인스턴스시작.

암호화 되지 않은 볼륨이 있다. 이볼륨을 암호화 할거다.

인스턴스를 중지한다.

임시스토리지 유실 안내가 나온다.

인스턴스가 중지되면 연결된 EBS를 찾아서 스냅샷을 진행한다.

tag 를 Name 로 설정하여 잘적자. 생성된 스냅샷으로 볼륨을 생성한다.

추가할 태그는 원래 볼륨에 붙어있던 태그에 -encrypt 태그를 추가하여 원래 볼륨과의 구별을 두자.

인스턴스에서 볼륨을 분리한다. 여기서 중요한점은 원래 마운트 되어있는 포지션이다.

볼륨을 연결한다 이때에 원래의 마운트 포지션에 연결해 준다.

중지된 인스턴스는 보인다.

디바이스 설정이 중요하다. 먼저 sdf 로 연결하고 인스턴스를 시작해 보겠다.

루트 디바이스가 없는 경우 시작이 안된다. 그래서 디바이스연결은 /dev/xvda 를 기억하라고 한것이다. 디바이스 마운트 포지션을 변경하려면 분리후 재연결 하여야 한다.

/dev/xvda 로 연결하면 루트 디바이스로 인식이 된다.

중지 상태인 인스턴스를 시작 하면 정상적으로 시작이된다.

이렇게 볼륨 암호화를 진행하여 보았다.

aws-linuxer의 블로그 톺아보기

그 동안 블로그를 운영하면서 블로그에 이것저것 적용해 보느라 시간 가는줄 몰랐다.

대략적인 블로그의 구성도를 그려보았고 구성도를 하나하나 풀어보는 시간을 가져보려한다.

먼저 내블로그는 apm 으로 이루어진 상태였다. 프리티어로 도메인도 없는 상태였고 그냥 테스트 용도 였다.

그 블로그를 먼저 rds 로 분리를 진행 했다.

인스턴스한대에 apache + php + mariadb 였던 구성에서 mariadb 를 rds 로 옮겼다.
그리고 php를 php-fpm 으로 교체 했다.

이시기엔 그냥 구성만 진행하려던 시기라 뭔가 많이 붙이지 않았다. 이 다음 과정에서 로드벨런서를 붙였다.

ALB를 붙이고 나서 letsencrypt 로 인증서를 붙일가 구매를 할까 고민을 하였으나 결국 ACM을 사용하였다.

ALB는 여러개의 인증서를 사용할수 있고 ACM 은 한개의 인증서당 여러개의 도메인을 넣을수있다. 나는 linuxer.name / *.linuxer.name 루트도메인과 와일드카드로 이루어진 두개의 도메인을 acm으로 사용하고 있다.

이다음 진행한 설정을 s3 upload 다.

s3로 이미지를 업로드하고 cloudfront 로 응답한다. 블로그의 응답속도가 굉장히 올라갔다.

cdn.linuxer.name 도메인은 acm 을이용하는데 버지니아 북부에 acm을 설정해야 한다.

업로드 설정을 마친 다음에는 HA를 구성해 보았다. 이과정에서 redis 나 세션을 공유하기 위한 고민을 하였는데 사실 로그인은 나만해서 의미가 없었다. 또한 upload 도 s3로 해서 그냥 정말로 인스턴스만 만들고 대상그룹에 추가만 하면 바로 multi zone 구성이 바로 되었다. 단순한 wp! 칭찬해

그다음엔 지금도 수시로 테스트위해서 켜고 끄는RDS의 multiaz 진짜 고가용성을 위해선 아니고 그냥….썼다.

이부분은 두가지 이유떄문에 설정을 진행했는데, 먼저 중국의 해커가 너무 접근이 많았다. 또한 블로그에 매일 비아그라 광고가 봇도아니고 손으로 직접올리는 사림이 있었다. IP는 신기하게 매번 조금씩 달랐지만 댓글을 좀 지우다가 귀찮아서 결국 국가 차단을 계획했다.

지오로케이션을 지용하여 중국과 스패머의 국가를 Null 로 라우팅 하였다.

중국과 스패머의 국가 이외엔 cloudfront 로 접근된다.
일반적인 캐싱이나 CDN이 아니라 dynamic cdn 방식이다. 조금이라도 ALB로 빨리 접근하기 위한 방법이나 …효과는 잘…아마 한국이라 그럴거다.

cf 는 버지니아 북부의 acm을 이용하여 도메인을 인증하고 인증된 도메인은 waf 연결된다. waf는 서울리전의 alb에 연결되어있다.

유저는 그럼 route53을통해 cf에 연결되어 waf 를 통과하고 alb에 연결되어 web ec2에 연결되고 rds의 데이터를 읽어서 페이지를 볼수있는거다.

생각보다 설명이 길었는데..아무튼 뭔가 많다.

대략적인 블로그의 구성도를 그리고 역할을 설명하였다.

내블로그지만 나름 재미있게 가꾼거 같다.

즐거운 저녁되시라!

aws-waf.ver2-review-2-test

Hostcenter 의 Acunetix 취약점 점검툴을 사용하였습니다.

https://www.hostcenter.co.kr/Security/security01.aspx

aws waf.ver2 관리형룰의 성능을 테스트 하고 싶었다.

마침 회사에 web 취약점 점검툴이 있었다. 그래서 테스트를 진행했다.

먼저 COUNT 모드로 점검을 진행했다.

총 점검시간 4시간 15000번의 리퀘스트가 있었다. 첫번째 테스트는 1월10일 두번째 테스트는 1월 30일 이었다.

빨리 진행하고 싶었는데 좀 바빳다.

1월10일 모니터링 모드 스캔 결과
1월 30일 차단모드 스캔결과

간략한 결과로만 봐도 high단계의 취약점이 사라리고 medium 단계의 취약점이 하나 사라졌다.

그럼 어떻게 막혔는지 리뷰를 해야하는데…

일단 테스트시간에 막힌 리퀘스트는 3000개 정도. 15000만건중 20%정도가 막혔다.

Description
Contains rules that are generally applicable to web applications. This provides protection against exploitation of a wide range of vulnerabilities, including those described in OWASP publications and common Common Vulnerabilities and Exposures (CVE).
Capacity: 700

룰중 가장 많은 Capacity 를 사용하는 AWS-AWSManagedRulesCommonRuleSet 룰에서 역시나 많은 지분을 차지했다.

분석결과를 설명하기 보단 waf 를 사용해서 확인한 취약점리포트의 일부를 공개하는쪽으로 블로깅을 마친다.

waf 사용전

waf 사용후

블로깅이 좀 애매한데 다음엔 로깅을 남겨서 다음 포스팅을 준비해보겠다.

aws-waf.ver2-review-1-setup

waf 가 리뉴얼 되어 ver2로 돌아왔다.

그동안엔 cloudformation을 이용하여 waf 사용했는데 이젠 그럴필요가 없어졌다.

https://github.com/aws-samples/aws-waf-sample
이전에 사용하던 방법

또한 매니지드 룰을 제공하여 어느정도 패턴까지 지원해서 아주 긍정적이고 사용이 간단하며, 비용 또한 여타 웹 방화벽들보다 굉장히 싼편이라 적극 추천을 한다.

미사여구는 여기까지. 먼저 설정하는 방법을 설명하겠다.

불편한 점은..

ACL 확인시에 페이지르 변경하게 되면 리전설정을 매번 다시해줘야한다는거..

overview 가 갱신이 느리다는거…완전 답답..그래도 거의 실시간으로 차단된부분을 보여주는거나

이렇게 그래프에서 드래그를 하면 그시간대에 발생한 로그만 따로 보여주는점 등은 매우 사용자 친화적이라 할수있다. 그리고.

이런식의 차단내용을 보여주는것을 보면 Waf 로의 역할을 다한거라 생각한다. 물론
로그설정을 하지 않으면 3시간 분의 로그만 보여주는점을 생각하면…좀 불편한 점도 있지만 가격이 모든것을 말해준다. 먼저 ACL 5$ rule 하나당 1$ 내가 사용하는 룰이 7개니까 12$ 100만건당 0.6$ 거의 13$면 한달동안 waf를 사용할수 있는거다.

셋팅은 두가지로 나뉜다.

Resource type를 cloudfront 로 설정하면 cf에 적용되고 regional 로 설정하면 리전기반 ALB 나 API gw에 연결된다.

acl을 생성하고 리소스를 연결하는 것을 추천한다. 가끔이 아니라 생성하면서 여러차례 연결에러가 발생했다. 생성은 잘되는데 연결하다 에러가 나서 단계별로 하자.

관리형 룰을 사용할수 있고 IP차단의 경우엔 own rule 로 설정할수 있다.

관리형룰은 4가지로 나눠지며 나는 aws 관리형 룰만 사용중이다.

Add to web ACL 을 활성화 하면 룰을 사용하게된다. 바로 차단모드로 작동한다. 그렇기에 모니터링을 진행한 후에 차단하고 싶다면 Set rules action to count 를 활성화해서 count 모드로 사용한다. 매우중요하다.

관리형룰은 WCUs라는 단위로 사용할수있다. 기본으로 1500을 사용가능하다. 사실 룰을 덕지덕지 발라서 테스트하려고 했으나…까였다..

증가 안해줬다ㅠㅠ

22일정도 사용중인데 심플한 사용법이 일반사용자도 편하게 만들어져서 긍정적이라 생각한다 또한 cloudwatch로 공격이나 룰의 사용지표를 확인할수 있다.

이건 사용후기고 이 다음 포스팅은 웹취약점 점검툴로 waf의 관리형 룰을 테스트한 내용을 포스팅 하겠다.

aws RDS-HA-type-change

rds ha 를 테스트 해보았다.

HA enable 활성화시에 다운타임은 없다.

HA enble -> instance type 변경 t2.micro -> t2.small

HA 동작 10.0.1.12->10.0.1.30

다운타임 3초내외

HA disable instance type 변경 t2.micro -> t2.small 동시설정

HA 동작 10.0.1.30 -> 10.0.1.13

다운타임 3초내외

나름 생각보다 빠른 fail over 였다.

aws-route53-review

요 며칠간 CF관련 이슈로 고민이 많았다.

ipv6 부터 SK LTE까지…

이문제가 발생한 원인은 먼저

SK LTE DNS 에서의 ipv6라우팅이 가장 큰 원인일테고..
같은 cloudfront에서도 발생하는 빈도차가 있었으므로 그 원인을 파악하고 해결하는 법을 서술하려고한다.

먼저 A alias는 ipv4로 라우팅한다. – A record 는 ipv4를 라우팅 하므로..

>linuxer.name
이름: linuxer.name
Addresses: 52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42

그렇다면 alias 를쓰는 사용자는 cf관련 문제를 겪지 않았을 것이다.

Route 53 별칭 레코드는 AWS 리소스와 같은 별칭 대상의 DNS 이름에 내부적으로 매핑됩니다. Route 53은 조정 작업과 소프트웨어 업데이트를 위해 별칭 대상의 DNS 이름과 연결된 IP 주소를 모니터링합니다. Route 53 이름 서버의 신뢰할 수 있는 응답에는 A 레코드(IPv4 주소에 대한 레코드) 또는 AAAA 레코드(IPv6 주소에 대한 레코드)와 별칭 대상의 IP 주소가 포함되어 있습니다.
https://aws.amazon.com/ko/premiumsupport/knowledge-center/route-53-create-alias-records/

내용을 확인해 보면 신뢰할수 있는 응답에 ipv4-ipv6를 응답하게 되어있다고 나와있다.

따라서..alias는 문제가 없었다.

그렇다면 문제가 있었을 cf는 무엇일까?

cname 을 사용하던 도메인들이다.

cname을 설정하면 이렇다.

>test2.linuxer.name
서버: UnKnown
Address: 210.219.173.151
권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2150:1a00:10:3683:b8c0:93a1
2600:9000:2150:8000:10:3683:b8c0:93a1
2600:9000:2150:c000:10:3683:b8c0:93a1
2600:9000:2150:6400:10:3683:b8c0:93a1
2600:9000:2150:8c00:10:3683:b8c0:93a1
2600:9000:2150:1000:10:3683:b8c0:93a1
2600:9000:2150:7800:10:3683:b8c0:93a1
2600:9000:2150:e200:10:3683:b8c0:93a1
52.85.231.10
52.85.231.111
52.85.231.68
52.85.231.42
Aliases: test2.linuxer.name

ipv6 와 ipv4를 모두응답한다. 이 경우 ipv6가 우선라우팅이 된다.

그래서 결국 route53 공식문서를 확인해보니 A/AAAA를 같이쓰라고 되어있다.

cloudfront 는 cname 을 제공하고 A record를 사용할경우 cloudfront 의 IP변경에 대응할수 없다. 그렇기 때문에 일반적으로 A alias 를 사용하라 한것이다.

명시적인 레코드의 분리를 뜻하는 것이다. 일반적으로 잘 발생하는 문제는 아닌것으로 보이나, cname 을 사용하게되면 이렇다.

일반적으로 도메인에 요청을 할때 레코드를 지정해서 쿼리하진 않는다.
그래서 cname 으로 요청하게되면 cname 에 연결된 모든 record가 응답하게 되고 그 결과 값에 따라서 ipv6 가 존재하면 ipv6 로 라우팅 된다.

nslookup 결과
>test2.linuxer.name
서버: dns.google
Address: 8.8.8.8권한 없는 응답:
이름: d19f2uxthc0s83.cloudfront.net
Addresses: 2600:9000:2139:e200:10:3683:b8c0:93a1
2600:9000:2139:fa00:10:3683:b8c0:93a1
2600:9000:2139:4c00:10:3683:b8c0:93a1
2600:9000:2139:7400:10:3683:b8c0:93a1
2600:9000:2139:5400:10:3683:b8c0:93a1
2600:9000:2139:aa00:10:3683:b8c0:93a1
2600:9000:2139:2600:10:3683:b8c0:93a1
2600:9000:2139:6c00:10:3683:b8c0:93a1
99.86.144.35
99.86.144.128
99.86.144.34
99.86.144.126
Aliases: test2.linuxer.name

따라서 route53을 사용할때 A/AAAA를 분리해서 사용하라는 말이다.

그런데 말입니다.

그런데 말입니다에 대한 이미지 검색결과

A레코드는 쓸수 없잖아? cf는 IP가 바뀌니까..

그래서 결론이 난다. 확실하게 정해준다.

A Alias AAAA alias 를 사용하는걸 권장한다.
같은계정내 자원이라면!

아니라면?

cname 을 사용할수 밖에 없다면 CloudFront 의 IPv6 를 끄자.

CloudFront Distributions > General > Enable IPv6

체크박스만 누르고 Yes, Edit 만 누르면 된다.

참쉽죠.

참곤란한 이슈였다. 참고-URL

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://tools.ietf.org/html/rfc3484?fbclid=IwAR0Ca2JDM55CpyhZSjtiR7EYhySfzADdLMRX2q-rWZoAM-z8BHbqismCQfk#section-2.1

읽어주셔서 감사하다!

aws route53 의 응답이상-1.

얼마전부터 route53 에서 cf 관련 느린이슈가 발생했다.

skt lte 망에서 발생하는 이슈인지 아니면 다른 이슈가 있는지 애매한 느낌이 있었다.

나도 ipv6 를 꺼서 지연문제가 해결될거라 생각했는데 조금 이상한 부분이 있어서 글을쓰게되었다.

먼저 route53의 응답이 이상하다.

linuxer.name 의 ns 레코드는

>linuxer.name
서버: [205.251.196.29]
Address: 205.251.196.29
linuxer.name nameserver = ns-1053.awsdns-03.org
linuxer.name nameserver = ns-1958.awsdns-52.co.uk
linuxer.name nameserver = ns-406.awsdns-50.com
linuxer.name nameserver = ns-544.awsdns-04.net

총 4개의 ns 를 가지고있다. 이 ns를 지정해보기로 한다.

>server ns-544.awsdns-04.net
기본 서버: ns-544.awsdns-04.net
Addresses: 2600:9000:5302:2000::1
205.251.194.32

서버를 ns-544.awsdns-04.net로 지정하면 ipv6 와 ipv4를 응답한다.

그 후에 다시 내도메인을 쿼리한다.

>linuxer.name
서버: ns-544.awsdns-04.net
Addresses: 2600:9000:5302:2000::1
205.251.194.32
*** ns-544.awsdns-04.net이(가) linuxer.name을(를) 찾을 수 없습니다. No response from server

그냥 도메인에 대한 응답인데..응답하지 않는다.

그럼 ns-544.awsdns-04.net 도메인의 서버IP인 205.251.194.32 로 쿼리를 날려본다.

>server 205.251.194.32
기본 서버: [205.251.194.32]
Address: 205.251.194.32

>linuxer.name
서버: [205.251.194.32]
Address: 205.251.194.32
linuxer.name internet address = 52.85.231.111
linuxer.name internet address = 52.85.231.10
linuxer.name internet address = 52.85.231.68
linuxer.name internet address = 52.85.231.42
linuxer.name nameserver = ns-1053.awsdns-03.org
linuxer.name nameserver = ns-1958.awsdns-52.co.uk
linuxer.name nameserver = ns-406.awsdns-50.com
linuxer.name nameserver = ns-544.awsdns-04.net
linuxer.name
primary name server = ns-1053.awsdns-03.org
responsible mail addr = awsdns-hostmaster.amazon.com
serial = 1
refresh = 7200 (2 hours)
retry = 900 (15 mins)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
linuxer.name name = 13.209.129.220
linuxer.name MX preference = 10, mail exchanger = mail.linuxer.name
linuxer.name ??? unknown type 257 ???

정리하자면 ipv4인 IP로 연결하면 응답하고 ipv6/ipv4로 응답하는 DNS로는 도메인에 대한 응답을 하지않는다…

이게 cf문제는 아니고 route53에서 ipv6 에 대한 응답을 정상적으로 못해서 발생하는 증상이 아닐까…하고 생각해본다..

다른의견이 있으시면 고견을 들려주시기 바란다.

https://www.facebook.com/groups/awskrug/permalink/2278291878939490/

https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/routing-to-cloudfront-distribution.html?fbclid=IwAR3xOqsWf-xhh5cB0AOQfLW7zTKr-Cvd6mJEHfgIX607K1Rv6_HavoLPsnE

추가 댓글도 있으니 참고하시기 바란다.

2020/01/28 추가

https://tools.ietf.org/html/rfc3484#section-2.1

rfs3484에 의해 route53은 정상적인 응답을 하는것으로 보인다.

발생한 문제는 SK LTE 망내의 DNS에서 ipv6를 사용하므로서 정상적으로 라우팅하지 못한 문제로 보인다.

추가적인 내용은 다음포스팅에서 진행하겠다.