I’ve configured the dnsupdate-rfc2136 to send updates to my external bind9 instance (not deployed on rancher). The updates are working, but my services are not being assigned fqdns. All of my services are deployed on the management network (currently, 10.42.0.0/16). I exposed ports for one of the services thinking that was why - exposed 0.0.0.0:port
The service is then added to my bind server, but with the bind servers IP.
My bind server is at 10.240.9.2, so I deployed dnsupdate with RFC2136_HOST 10.240.9.2 and added the label to my host: io.rancher.host.external_dns_ip": “10.240.9.2”
When I inspect the services with ‘View in API’ I see that fqdn is set to null. What am I missing?
So I discovered that the io.rancher.host.external_dns_ip is not the IP of the DNS server, but the IP that should be reported to the DNS server for the hostnames. This means that the ports must be exposed to the host, rather than the dns update reporting the managed IP address. Would it be possible to add that as a potential behavior? I can set up routing outside to route to the rancher host for any IP in the rancher managed network. This would allow me to reuse ports for several services rather than need to do all sorts of wacky port mappings from host to containers.
You are correct, as stated here (https://docs.rancher.com/rancher/v1.5/en/cattle/external-dns-service/#using-a-specific-ip-for-external-dns) the IP that is used when registering the host in Rancher will be used as IP for the DNS record. You can override that by using the label io.rancher.host.external_dns_ip. So as the service is called external-dns it was built with exposed services in mind and registering the address of the host to reach it. I can see why it could be handy to expose the records somewhere else. I’ve found issue 3255 here which almost covers your use-case, would you take a look and update the issue with your request?