New ddns methods in ASA 9.15.1

[amozgovoy]

Hi all - has anybody tried to use the new web update-url for ddns introduced in 9.15.1?

How I can make it work with dnsomatic.com?

My config is:

ddns update method dnsomatic_web
  web update-url https://username:password@updates.dnsomatic.com/nic/update?hostname=<h>&myip=<a>
  web update-type ipv4
!

interface GigabitEthernet1/1
  description Connected to Cable Modem
  nameif outside
  security-level 0
  ddns update hostname all.dnsomatic.com
  ddns update dnsomatic_web
  ip address dhcp setroute
!

Don't know if its needed, but I also configured a ca trustpoint, as described in https://www.cisco.com/c/en/us/td/docs/security/asa/asa915/configuration/general/asa-915-general-config/basic-dhcp-ddns.html#task_176A466D16D7497694EEE7F1E01D39CC - downloaded a "HydrantID SSL ICA G2" intermediate CA certificate and installed it via:

crypto ca trustpoint DDNS_Trustpoint
  enrollment terminal
crypto ca authenticate DDNS_Trustpoint nointeractive
 ....
 ....
 quit

however, if a check the update status via 

show ddns update interface outside

what I'm getting is:

sh ddns update interface outside

Dynamic DNS Update on outside:
Update Method Name Update Destination
dnsomatic_web not available

Last Update attempted on 07:45:14.815 UTC Mon Nov 9 2020
Status : Failed
Reason : Could not establish a connection to the server

I can ping the ddns host, so the issue likely is not the connectivity, but ssl:

ping updates.dnsomatic.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 146.112.255.155, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 ms

I can confirm if I curl that ddns url from the box inside of my network, I see it works (I see the confirmation in the email from dnsomatic), so it is not the credentials issue either.

I've tried to enable the debug mode (debug ddns) and initiate the update, but it doesn't help much:

DDNS update request = /nic/update?hostname=all.dnsomatic.com&myip=<masked_my_ip>
asa(config-if)# Failed to send HTTP(s) request
DDNS: Another update completed, outstanding = 0
DDNS: IDB SB total = 0

I'd appreciate any help about what to try next - thank you!

[Mohammed al Baqari]

Hi,

Do you have HTTPs server enabled on you ASA. Its unable to
initiate request. You can confirm this as well by enabling packet capture
on ASA outside to see if any traffic is leaving.

Finally, enable the term monitor and see what logs are displayed when you
initiate the test.

***** please remember to rate useful posts

[amozgovoy]

thank you for your reply!

why would I need a HTTPs server on ASA for that? What I'm trying to do is to ask dnsomatic.com (https://www.dnsomatic.com/docs/api) to update the linked dynamic dns accounts with my ASA public ip address.

[Mohammed al Baqari]

But you need to have ASA to create the HTTP request and this is failing.
Try it and see if it works.

[amozgovoy]

So to be clear, I need an HTTPS server enabled on my ASA to make a client (curl-like) request to the outside 3rd party HTTPS web server? If this is correct, I'll try that.

[Mohammed al Baqari]

Yes that is correct. Otherwise ASA won't be able to build HTTPs messages.

***** please remember to rate useful posts

[erik.dalera]

Hi, I have a question regarding the ddns update on an ftd 6.7 managed by fmc. It seems that it can only grab the "outside" ip interface and not the public ip of the interface. We have a couple of sites that have private ipadress on outside and public nated.. But i cant get it to update the public ip.. This would be easy to just remove the &myip=<a> but the FMC gui i cant do this. And cant create this with flexconfig.. any idea?

[ronbuchalski]

I had the same problem, and I just figured it out.  I am using Dynu rather than dnsomatic, but they both use the same mechanism to update DDNS records.

First of all, I am using an ASA-5506X, and running version 9.16.2 (asa9-16-2-lfbff-k8.SPA).

One thing that the Cisco documentation does not state is that it is REQUIRED to use an HTTPS URL.  While Dynu (and likely dnsomatic as well) show options for using HTTP or HTTPS URLs, the Cisco ASA does not work unless it's an HTTPS URL.

Since the HTTPS URL is required, so is the creation of a CA Trustpoint for the website.  I verified that the CA certificate used to create the trustpoint matched the intermediate CA that I downloaded, by matching the serial number.  It looks like you followed the correct procedure, so as long as you verified that you downloaded the correct intermediate CA, and it was installed properly, that portion should be good (according to what you posted).

I also wasted lots of time trying variations of the update-url, and while I did it, I had a packet capture running on my outside interface, looking for DNS requests for the update URL.  And I never saw them.  So, there is some DNS configuration that you need to set up in order for the ASA to correctly resolve the URL into an IP address.

I use Cloudflare for DNS, so I set this up on my firewall:

First, to tell the firewall to perform DNS domain-lookups for public (outside) destinations

dns domain-lookup outside

Then, to tell the firewall which DNS servers to use for its lookups.  I used the DefaultDNS server-group, but you can create your own:

DNS server-group DefaultDNS
name-server 1.1.1.1 outside
name-server 1.0.0.1 outside

But the other thing I realized (referring back to the first point), is that if the firewall does not like something about the update-url, it can issue an error when you enter it, meaning the syntax is not correct for the ASA.  BUT IT WILL ACCEPT A URL THAT DOES NOT WORK, AND NOT GIVE YOU AN ERROR OR WARNING ABOUT IT!!!  So, that's why I thought I was fine with an HTTP URL, yet I never saw anything going out from the firewall to resolve the name for the Dynu URL (api.dynu.com).

The other thing I'm not sure of in your configuration is the hostname that you have used on your outside interface.  Is 'all.dnsomatic.com' (or whatever you are actually using) the Fully Qualified Domain Name for your DDNS domain?  That's the name that they use in their example to set up the ddclient, so that would not be correct for you.

See: https://www.dnsomatic.com/docs/ddclient

So, when you configure the hostname for DDNS updates on your outside interface, using ddns update hostname <foo.bar.com>, that needs to be your actual DDNS FQDN.  If you are something other than the actual FQDN you need to update, then that's not correct, and it won't work.

Also, that tip another commenter made about needing to enable HTTPS on the firewall for this to work is just plain WRONG.  There is no need to enable an HTTPS Server on the ASA in order for it to act as a web CLIENT to update your DDNS records with dnsomatic.

Hope this helps, if you have not figured it out yet.  Or, if you did, maybe it will help someone else.

-rb

[amozgovoy]

I had a case with TAC opened for a month or so and we figured out there is an issue with the ASA code, particularly with the scenarios when the same IP address serves two or more hostnames. In case of dnsomatic service these are `updates.dnsomatic.com` and `api.opendns.com`.

note the IP address for updates.dnsomatic.com:

$ curl -vvv https://updates.dnsomatic.com
* Trying 146.112.255.155:443...
* Connected to updates.dnsomatic.com (146.112.255.155) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=www.dnsomatic.com; O=Cisco Systems Inc.; L=San Jose; ST=California; C=US
* start date: Aug 17 20:48:34 2021 GMT
* expire date: Aug 17 20:48:33 2022 GMT
* subjectAltName: host "updates.dnsomatic.com" matched cert's "updates.dnsomatic.com"
* issuer: C=US; O=IdenTrust; OU=HydrantID Trusted Certificate Service; CN=HydrantID Server CA O1
* SSL certificate verify ok.

and then when we try to connect to directly to 146.112.255.155:

$ curl -vvv https://146.112.255.155
*   Trying 146.112.255.155:443...
* Connected to 146.112.255.155 (146.112.255.155) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cisco OpenDNS LLC; CN=api.opendns.com
*  start date: Jun  8 00:00:00 2021 GMT
*  expire date: Jun 13 23:59:59 2022 GMT

So ASA, apparently, tries to connect using an IP address and it gets the certificate default for that IP, in this case it is `api.opendns.com`. Obviously, it can't establish a secure connection using the certificate from a different domain, that's why the connection fails and ASA can't register the interface's IP address at the service. It might work for Cloudlare or other services if the certificate for the IP matches the certificate for hostname. There is a ticket for that issue got created as a result of our investigation, but not sure if Cisco will fix it any time soon as seems like it is not considered as a high priority.

[ronbuchalski · Accepted solution]

I searched through the bug ID tool to see if there was an issue related to DDNS on the ASA that got fixed between 9.15.x and 9.16.x, but couldn't find anything.  I did find the DDTS ticket opened for your issue:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvy64790

With that said, I call BS on Cisco TAC's 'resolution' of your issue.  I work as a network engineer, and have extensive experience working with load balancers and content switching.  It is totally possible to set up multiple URLs, even to different domains, all from the same public IP address, provided that the public IP address is presented via a content switching load balancer.  If that's done, then the load balancer looks at the requested URL, and using content switching, will direct the request to the correct load balancer handling the servers that can answer the request.

Just as your example shows, when going to https://updates.dnsomatic.com the request gets directed to the appropriate load balancer front ending the servers that handle the update requests.  If this did not work, standalone clients such as ddclient would also fail to update DNS records.

I still believe that it's a configuration issue on your ASA that is preventing the update from being sent.  Have you run a packet capture to see whether the requests are being sent out, and what the replies are?  Or, if there even IS a reply?

One area I mulled over for quite a bit (because the documentation is pretty lame) deals with specifying the FQDN that you want to update with the IP address.  According to the documentation, you need to specify the FQDN that will be sent to the DDNS provider.  It can be done in several different ways (per my interpretation of the documentation):

1) Specifically LIST the FQDN on the interface that will be sending out the updates (outside interface), using the ddns update hostname command.

2) Give the ASA a hostname of the FQDN for your site

3) Give the ASA a hostname, combined with defining the domain in the DNS server-group DefaultDNS (or other group).

As an example, say your FQDN is myvpn.domain.com. This domain can be defined to be sent for DDNS updates in one of three ways.

1. Configure explicitly on the interface:

interface GigabitEthernet1/2
 nameif outside
 security-level 0
 ddns update hostname myvpn.domain.com
 ddns update dynu
 ip address dhcp setroute

2. Configure the ASA host name as your FQDN:

hostname myvpn.domain.com

interface GigabitEthernet1/2
 nameif outside
 security-level 0
 ddns update dynu

3. Configure the ASA host name, and define the domain in the dns server-group DefaultDNS

hostname myvpn

ASA5506X# show run dns server-group
DNS server-group DefaultDNS
 name-server 1.1.1.1 outside
 name-server 1.0.0.1 outside

 domain-name domain.com

interface GigabitEthernet1/2
 nameif outside
 security-level 0
 ddns update dynu

So, in Cases 2 and 3, you don't explicitly define the FQDN on the interface which has the IP to be updated, so the ASA will use one of those other methods to determine what the FQDN should be.

I am using Method 1.  The hostname of my ASA is not related to the FQDN at all, and I have NOT defined a domain name in the DNS server-group DefaultDNS.  In fact, I found a bug which seemed to indicate that if you defined the ddns update hostname on the outside interface AND defined a domain-name in the DNS server-group that the ASA would actually send the FQDN to the DDNS provider as myvpn.domain.com.domain.com (appending the domain to the FQDN!).

In any case, I reviewed the dnsomatic setup instructions:

https://dnsomatic.com/docs/api

And they are identical to the setup for Dynu, with the exception of the update URL being updates.dnsomatic.com versus api.dynu.com.

My DDNS update config is:

ddns update method dynu
web update-url https://myacctname:updatepw@api.dynu.com/nic/update?hostname=<h>&myip=<a>
web update-type ipv4

The ASA will fill in <h> with a hostname based on what I explained above, and will fill in <a> with the IP address of the outside interface (the interface where the ddns update commands are configured, and either the IPv4 address, an IPv6 address, or both, depending on what you define using the web update-type command in the ddns update method.

I'm not sure that you saw in my previous comment about the FQDN you are using.  Your initial post implied that you had the outside interface configured as:

ddns update hostname all.dnsomatic.com

But is 'all.dnsomatic.com' your FQDN?  I doubt it, as your domain is probably NOT a dnsomatic domain, just like my real FQDN is not a dynu.com domain, but is a one of many dynamic DNS domains that dynu hosts.  So, if that update hostname is not correct, then you won't be updating anything.

But your error when trying to update, which you had in your original post:

DDNS update request = /nic/update?hostname=all.dnsomatic.com&myip=<masked_my_ip>
asa(config-if)# Failed to send HTTP(s) request
DDNS: Another update completed, outstanding = 0
DDNS: IDB SB total = 

This indicates that you ARE using all.dnsomatic.com as the FQDN you want to update.  Which again, I doubt that it's your real FQDN, because:

mymac ~ % nslookup all.dnsomatic.com
Server: 10.41.4.242
Address: 10.41.4.242#53

** server can't find all.dnsomatic.com: NXDOMAIN

In any case, the error doesn't say the request was rejected by dnsomatic, but that the ASA failed to send your request.  And this was the same error I was getting, until I set up the trustpoint for the intermediate certificate used by dynu, and set up my update URL to use HTTPS.

When it DOES successfully work, you'll see the success message like this:

ASA5506X# show ddns update interface

Dynamic DNS Update on outside:
Update Method Name                       Update Destination
dynu                                                  not available

Last Update attempted on 00:11:05.379 CST Thu Nov 25 2021
Status : Success
FQDN : myvpn.domain.com
IP addresses : 72.190.###.###

The date/time of the update will be listed, as well as the Status (Success), and the information that was successfully updated (FQDN and IP addresses).