implement a "real" DNS response cache

.gitlab-ci.yml

@@ -1,4 +1,5 @@
 stages:
+  - prepare
   - test
   - container
 
@@ -13,14 +14,24 @@ before_script: &before_script
 .check:otp: &check_otp
   stage: test
   image: erlang
+  services:
+    - quay.io/travelping/ergw-dns-test-server:latest
   artifacts:
     when: always
     untracked: true
     paths:
       - _build
     reports:
       junit: _build/test/logs/report.xml
+  before_script:
+    - apk update
+    - apk --no-cache upgrade
+    - apk --no-cache add git zip iproute2
+    - ps xaw
   script:
+    - export CI_DNS_SERVER=127.0.0.1
+    - cat /etc/hosts
+    - ss -aun
     - sh -c 'echo 0 > /proc/sys/net/ipv6/conf/all/disable_ipv6'
     - ip addr add fd96:dcd2:efdb:41c3::10/64 dev lo
     - ip addr add fd96:dcd2:efdb:41c3::11/64 dev lo
@@ -87,3 +98,30 @@ docker:
              --platform=linux/arm64,linux/amd64 \
              --push --no-cache .
   when: always
+
+dns-server:
+  image: jdrouet/docker-with-buildx:stable
+  stage: prepare
+  dependencies: []
+  variables:
+    REGISTRY: "quay.io"
+    BUILD_IMAGE: "travelping/ergw-dns-test-server"
+  services:
+    - docker:dind
+    - linuxkit/binfmt:v0.8
+  script:
+    - docker version
+    - docker buildx ls
+    - docker buildx inspect --bootstrap
+    - docker login -u ${QUAY_USER_ID} -p ${QUAY_TOKEN} ${REGISTRY}
+    - |
+      cd docker/dns-test-server
+      docker buildx build \
+             -t ${REGISTRY}/${BUILD_IMAGE}:latest \
+             --platform=linux/arm64,linux/amd64 \
+             --push --no-cache \
+             -f Dockerfile .
+  only:
+    changes:
+    - docker/dns-test-server/Dockerfile
+    - docker/dns-test-server/dns_data/*

README.md

@@ -489,6 +489,38 @@ Eshell V11.0.3  (abort with ^G)
 
 The configuration is documented in [CONFIG.md](CONFIG.md)
 
+## RUNNING UNIT TEST
+
+Unit test can be run local with:
+
+```sh
+$ rebar ct
+```
+
+In order to run the IPv6 a number of locap IPv6 addresses have to be added to the host.
+Check .travis.yml or .gitlab-ci.yml the list.
+
+The DNS resolver tests can be run with a local DNS server. The docker image use with
+the CI test can also be use for that.
+
+Run it with:
+```sh
+docker run -d --rm \
+        --name=bind9 \
+        --publish 127.0.10.1:53:53/udp \
+        --publish 127.0.10.1:53:53/tcp \
+        --publish 127.0.10.1:953:953/tcp \
+        quay.io/travelping/ergw-dns-test-server:latest
+```
+
+and
+
+```sh
+export CI_DNS_SERVER=127.0.10.1
+```
+
+before running the unit tests.
+
 <!-- Badges -->
 [travis]: https://travis-ci.com/travelping/ergw
 [travis badge]: https://img.shields.io/travis/com/travelping/ergw/master.svg?style=flat-square

docker/dns-test-server/Dockerfile

@@ -0,0 +1,3 @@
+FROM internetsystemsconsortium/bind9:9.11
+
+COPY    dns_data/* /etc/bind

docker/dns-test-server/build.sh

@@ -0,0 +1,9 @@
+#!/bin/bash
+
+REGISTRY="quay.io"
+BUILD_IMAGE="travelping/ergw-dns-test-server"
+
+docker buildx build \
+       -f Dockerfile \
+       --platform=linux/arm64,linux/amd64 -t ${REGISTRY}/${BUILD_IMAGE}:latest \
+       --push --no-cache .

docker/dns-test-server/dns_data/CS_APN_DB.txt

@@ -0,0 +1,46 @@
+; 
+;
+imsTV1.apn                                   (
+;  IN NAPTR order pref. flag service                           regexp replacement
+   IN NAPTR 100   999   "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp"         "" topoff.vip1.gw01.nodes )
+   IN NAPTR 200   999   "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp"         "" topoff.vip1.gw21.nodes
+   IN NAPTR 300   999   "a" "x-3gpp-pgw:x-gn:x-gp"                 "" topoff.vip3.gw01.nodes
+   IN NAPTR 400   999   "a" "x-3gpp-pgw:x-gn:x-gp"                 "" topoff.vip3.gw21.nodes
+;  IN NAPTR 500   999   "a" "x-3gpp-pgw:x-s8-pmip"                 "" topoff.vip2.gw01.nodes
+;  IN NAPTR 600   999   "a" "x-3gpp-pgw:x-s8-pmip"                 "" topoff.vip2.gw21.nodes
+
+;
+;  Operator has imsTV1.apn using gw01.nodes when possible. Possibly one IMS core and video server
+;  are closer to gw01.nodes than gw21.nodes
+;
+;  Operator does not support PMIPv6
+;  The operator does support Gn/Gp
+
+
+imsTV2.apn                                   (
+;  IN NAPTR order pref. flag service                           regexp replacement
+   IN NAPTR 100   999   "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp"         "" topoff.vip1.gw21.nodes )
+   IN NAPTR 200   999   "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp"         "" topoff.vip1.gw01.nodes
+   IN NAPTR 400   999   "a" "x-3gpp-pgw:x-gn:x-gp"                 "" topoff.vip3.gw01.nodes
+   IN NAPTR 300   999   "a" "x-3gpp-pgw:x-gn:x-gp"                 "" topoff.vip3.gw21.nodes
+;  IN NAPTR 600   999   "a" "x-3gpp-pgw:x-s8-pmip"                 "" topoff.vip2.gw01.nodes
+;  IN NAPTR 500   999   "a" "x-3gpp-pgw:x-s8-pmip"                 "" topoff.vip2.gw21.nodes
+;
+;  This is almost the same as imsTV1. 
+;  However, NAPTR order values for a particular interface type are reverse in comparision 
+;  to imsTV1.apn
+;
+;  Operator has imsTV2.apn using gw21.nodes when possible.
+
+
+topo.apn                                   (
+;  IN NAPTR order pref. flag service                           regexp replacement
+   IN NAPTR 100   999   "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp"         "" topon.vip1.gw21.nodes )
+   IN NAPTR 200   999   "a" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp"         "" topon.vip1.gw01.nodes
+   IN NAPTR 400   999   "a" "x-3gpp-pgw:x-gn:x-gp"                 "" topon.vip3.gw01.nodes
+   IN NAPTR 300   999   "a" "x-3gpp-pgw:x-gn:x-gp"                 "" topon.vip3.gw21.nodes
+
+; Obviously more APN would exist for a real operator
+
+;
+; end of file

docker/dns-test-server/dns_data/CS_EX.txt

@@ -0,0 +1,15 @@
+$ORIGIN epc.mnc990.mcc311.3gppnetwork.org.
+;
+$TTL 3600 ; 1 hour - this directive is defined in IETF RFC 2308 not RFC 1035
+;
+$INCLUDE /etc/bind/SOA_DB.txt
+;
+$INCLUDE /etc/bind/CS_MME_DB.txt
+;
+$INCLUDE /etc/bind/CS_SGW_PGW_NODE_DB.txt
+;
+$INCLUDE /etc/bind/CS_TAI_DB.txt
+;
+$INCLUDE /etc/bind/CS_APN_DB.txt
+;
+; End of file

docker/dns-test-server/dns_data/CS_MME_DB.txt

@@ -0,0 +1,71 @@
+;
+; This is the GUTI related record and the MME node record 
+; The operator has decided to use the 3GPP name as the canononical node name of the MME
+; rather than having two records (the 3GPP one and an operator defined value)
+;
+mmec01.mmegi8001.mme                      (
+;    IN NAPTR order pref. flag service                    regexp  replacement
+     IN NAPTR 100   999   "a"   "x-3gpp-mme:x-s10"            ""  topoff.eth1.mmec01.mmegi8001.mme )
+     IN NAPTR 200   999   "a"   "x-3gpp-mme:x-s11"            ""  topoff.eth3.mmec01.mmegi8001.mme
+;    IN NAPTR 300   999   "a"   "x-3gpp-mme:x-s3"             ""  topoff.eth5.mmec01.mmegi8001.mme
+;    IN NAPTR 400   999   "a"   "x-3gpp-mme:x-gn"             ""  topoff.eth6.mmec01.mmegi8001.mme
+;    IN NAPTR 500   999   "a"   "x-3gpp-mme:x-s1-mme"         ""  topoff.eth7.mmec01.mmegi8001.mme
+
+;  This particular operator only supports LTE access in their accesses etc.  
+;  So the S3 record is commented out above. If the operator wants the MME to be used with S3/S4
+;  SGSN nodes then the record would have to be included. 
+;  The Gn/Gp interface is commented out for same reason. This operator does not support it. 
+;  If the operator wants the MME to be used for Gn/Gp SGSN interworking
+;  then the record would have to be included. 
+;
+;   Reminder: Canonical node name records must be complete.
+;   However, "x-3gpp-mme:x-s1-mme" is an exception.  
+;   While S1-MME interface must be physically present and used in a MME
+;   it is explicitly optional for an operator to provision in this release of 3GPP
+;.  So it too is commented out
+
+; NAPTR order plays no major role in this particular example since the MME node is already 
+; selected in GUTI case and as a canonical node name. In most cases the interface type 
+;(S10 vs S11 etc) is functionally determined so the NAPTR order is rarely used in this record set
+; If the S3 and Gn records were not commented out the S10 is preferred over S3 over Gn 
+; I.e. a combined MME/SGSN  could communicate to the MME above using any of the three protocols 
+; at context transfer. 
+; So the operator is stating that S10 is preferred over S3 over Gn
+;
+; Of course if the MME had multiple S10 interfaces 
+; the operator could provision more than one S10 record with different orders 
+; perhaps to select S10 IPv6 over S10 IPv4
+
+
+; We have the same type of records for the other MME (same comments would apply)
+
+;
+mmec02.mmegi8001.mme                      (
+;    IN NAPTR order pref. flag service                    regexp  replacement
+     IN NAPTR 100   999   "a"   "x-3gpp-mme:x-s10"            ""  topoff.eth1.mmec02.mmegi8001.mme )
+     IN NAPTR 200   999   "a"   "x-3gpp-mme:x-s11"            ""  topoff.eth3.mmec02.mmegi8001.mme
+;    IN NAPTR 300   999   "a"   "x-3gpp-mme:x-s3"             ""  topoff.eth5.mmec02.mmegi8001.mme
+     IN NAPTR 400   999   "a"   "x-3gpp-mme:x-gn"             ""  topoff.eth6.mmec02.mmegi8001.mme
+;    IN NAPTR 500   999   "a"   "x-3gpp-mme:x-s1-mme"         ""  topoff.eth7.mmec02.mmegi8001.mme
+;
+;
+; All MME IP addresses for both MME
+;
+topoff.eth1.mmec01.mmegi8001.mme IN A 192.0.2.11
+                                 IN A 192.0.2.12
+                                 IN AAAA 2001:db8:0:0:0:0:0:0
+                                 IN AAAA 2001:db8:0:1:0:0:0:0
+topoff.eth3.mmec01.mmegi8001.mme IN A 192.0.2.13
+                                 IN A 192.0.2.14
+                                 IN AAAA 2001:db8:0:2:0:0:0:0
+                                 IN AAAA 2001:db8:0:3:0:0:0:0
+topoff.eth1.mmec02.mmegi8001.mme IN A 192.0.2.17
+                                 IN A 192.0.2.18
+                                 IN AAAA 2001:db8:0:6:0:0:0:0
+                                 IN AAAA 2001:db8:0:7:0:0:0:0
+topoff.eth3.mmec02.mmegi8001.mme IN A 192.0.2.19
+                                 IN A 192.0.2.110
+                                 IN AAAA 2001:db8:0:8:0:0:0:0
+                                 IN AAAA 2001:db8:0:9:0:0:0:0
+
+; end of file