nsupdate does not work for NS and MX records
nerdlich opened this issue · 9 comments
The module is using dig to test the nameserver for its current record and find out whether an update is needed. This does not work for NS and MX records, because the nameserver always replies with an IP address and not with the name that is actually assigned to the record:
$ dig @127.0.0.1 -c IN +noall +answer github.com MX
github.com. 30 IN A 192.30.252.130
However, the actual MX records are:
$ dig @127.0.0.1 +short github.com MX
10 mxa-00184f01.gslb.pphosted.com.
10 mxb-00184f01.gslb.pphosted.com.
This leads to the following nsupdate input that obviously fails:
server 127.0.0.1
zone github.com
update delete github.com. 30 IN MX 192.30.252.130
update add github.com. 30 IN MX 10 mxa-00184f01.gslb.pphosted.com.
update add github.com. 30 IN MX 10 mxb-00184f01.gslb.pphosted.com.
I would suggest to "hardcode" MX and NS records in the zone definition and not using dynamic updates for these.
After fussing about on the command line for a few minutes, it looks like the issue is actually with the specification of class IN. Without specifying any class, the dig command returns the expected data. I don't understand why explicitly setting it to IN changes this since it's the default, but it does. I would rather avoid building support for both "hardcoded" records and dynamic records in the same zone. It looks like it should be possible to fix the dynamic resource.
Here's the strangeness:
[inkblot@toto:~]$ dig @127.0.0.1 -c IN +noall +answer github.com MX
github.com. 20 IN A 192.30.252.128
[inkblot@toto:~]$ dig @127.0.0.1 +noall +answer github.com MX -c IN
github.com. 208 IN MX 10 mxa-00184f01.gslb.pphosted.com.
github.com. 208 IN MX 10 mxb-00184f01.gslb.pphosted.com.
Could you please try my dynamic-mx-fix branch to see if it fixes your problem?
Hey, thanks for your fast response! It fixes the problem...half way. Now, you just need to match the full record into rrdata, and not only e.g. '10' in case of a MX record.
Maybe
linearray = line.chomp.split(/\s+/, 5)
in line 116.
Ah, yes, MX records (SOA and SRV, too, for that matter) have rrdata that contain spaces. The provider will have to join linearry[4+] back together.
I've committed your suggested fix. Could you please try the branch again?
Yeah, I already put that in my forked branch and it worked. Now I'm trying to figure out how to deal with the serial in SOA updates... ;)
Thanks for your help!
I'll merge the branch and cut a release.
Personally, I do a lot of dynamic updates manually. I hadn't even considered what might be necessary to manage an SOA using dns_rr.