search

inkblot / puppet-bind

18 stars 82 forks source link

nsupdate does not work for NS and MX records #1

Closed nerdlich closed 10 years ago

nerdlich commented 10 years ago

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.

inkblot commented 10 years ago

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.

inkblot commented 10 years ago

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.
inkblot commented 10 years ago

Could you please try my dynamic-mx-fix branch to see if it fixes your problem?

nerdlich commented 10 years ago

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.

nerdlich commented 10 years ago

Maybe

linearray = line.chomp.split(/\s+/, 5)

in line 116.

inkblot commented 10 years ago

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.

inkblot commented 10 years ago

I've committed your suggested fix. Could you please try the branch again?

nerdlich commented 10 years ago

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!

inkblot commented 10 years ago

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.