Wanted to take a moment and thank everyone for their help & suggestions
on this.
Apologies for the frantic nature of my prior messages - was trying to
debug too much at once while troubleshooting this.
For the record, it was absolutely a backend-inconsistency issue as
suggested. Don't recall exactly why this install had been running the
opendbx backend. Things had been working but this was an old-install,
so it was the spinning up of this new slave that triggered the situation
with the inconsistency.
At any rate, ended up dumping all tables and starting compeletly fresh
on the master and all slaves, now running the gmysql connector. Things
are working BEAUTIFULLY!!! Supermaster auto-delegation is working great.
Just so I understand correctly - I've read a fair bit about autoserial's
behavior having changed over a couple versions. The way I understand it
to be behaving now (3.3) is that upon submission/change of a record, the
change_date field needs updated to be of the format YYYYMMDDxx. This in
turn then causes the notified_serial value to be updated, which is then
reflected in DNS lookups. Is this correct?
Cheers,
-Chris
On 2/18/14 5:11 PM, Chris Moody wrote:
Sorry - my mistake again re: multiple SOA - RFC 1034, page 28/29.
Still stumped about what would be causing the 'Remote 206.71.169.116
tried to sneak in out-of-zone data ''|SOA during AXFR of zone
'mysitehealth.com', ignoring' failure.
The supermaster auto-provision bit worked as the slave shows the
domain in the domains table. Just won't actually axfr the records.
-Chris
On 2/18/14 4:51 PM, Chris Moody wrote:
Replies inline.
On 2/18/14 2:56 PM, Aki Tuomi wrote:
On Tue, Feb 18, 2014 at 02:47:33PM -0500, Chris Moody wrote:
Could all this perhaps be related to using opendbx as the backend?
=====
Feb 18 19:25:22 nyny-dp-1 pdns[7979]: Received NOTIFY for
mysitehealth.com from 206.71.169.116 for which we are not
authoritative
Feb 18 19:25:23 nyny-dp-1 pdns[7979]: Unable to find backend willing
to host mysitehealth.com for potential supermaster 206.71.169.116. 4
remote nameservers:
=====
This issue is due to misconfiguration for supermasters. The
supermasters table
must have matching hostname and ip address in it. It has to match
ns1.mysitehealth.com and 206.71.169.116.
Face palm - my mistake on this bit. When I dropped the table I
forgot to re-add the supermaster records. They're back and again
reporting the AXFR issue.
Here's the brand new zone that's got the same issue.
=====
mysql> SELECT * FROM records WHERE domain_id = 635;
+-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+
| id | domain_id | name | type | ttl | prio |
content | ordername | auth | disabled |
+-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+
| 35276 | 635 | mysitehealth.com | SOA | 86400 | NULL |
ns1.mysitehealth.com. [email protected] 0 10800 3600
604800 3600 | NULL | NULL | NULL |
| 35277 | 635 | ns1.mysitehealth.com | A | 120 | NULL |
206.71.169.116 | NULL | NULL | NULL |
| 35278 | 635 | ns2.mysitehealth.com | A | 120 | NULL |
64.106.186.196 | NULL | NULL | NULL |
| 35279 | 635 | mysitehealth.com | NS | 120 | NULL |
ns1.mysitehealth.com | NULL | NULL | NULL |
| 35280 | 635 | mysitehealth.com | NS | 120 | NULL |
ns2.mysitehealth.com | NULL | NULL | NULL |
| 35282 | 635 | mysitehealth.com | MX | 120 | 10 |
mx1.node-nine.com | NULL | NULL | NULL |
+-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+
6 rows in set (0.00 sec)
mysql>
=====
Can you try dig axfr mysitehealth.com @localhost (if you have axfr
from localhost permitted)
Please check master logs as well
So this is strange - I -do- see duplicate SOA records in the axfr but
not in the master's DB.
ex>
=====[ master ]=====
mysql> SELECT * FROM records WHERE name = "." OR name = "";
Empty set (0.00 sec)
=====
=====[ dig axfr @ master ]=====
root@nyny-dp-1 ~ # dig @206.71.169.116 mysitehealth.com axfr
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>>
@206.71.169.116 mysitehealth.com axfr
; (1 server found)
;; global options: +cmd
. 86400 IN SOA ns1.mysitehealth.com.
postmaster.mysitehealth.com. 61 10800 3600 604800 3600
ns1.mysitehealth.com. 120 IN A 206.71.169.116
ns2.mysitehealth.com. 120 IN A 64.106.186.196
mysitehealth.com. 120 IN NS ns1.mysitehealth.com.
mysitehealth.com. 120 IN NS ns2.mysitehealth.com.
mysitehealth.com. 120 IN MX 10 mx1.mysitehealth.com.
mx1.mysitehealth.com. 120 IN A 206.71.169.116
www.mysitehealth.com. 120 IN A 206.71.169.116
. 86400 IN SOA ns1.mysitehealth.com.
postmaster.mysitehealth.com. 61 10800 3600 604800 3600
;; Query time: 144 msec
;; SERVER: 206.71.169.116#53(206.71.169.116)
;; WHEN: Tue Feb 18 21:40:53 2014
;; XFR size: 9 records (messages 3, bytes 326)
=====
Now I suppose it begs the question, why are there duplicate SOA's
being returned when they're not in the DB?
(I -REALLY- appreciate the help on this)
-Chris
Cheers,
-Chris
On 2/18/14 2:14 PM, Aki Tuomi wrote:
SELECT * FROM records WHERE domain_id =
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
_______________________________________________
Pdns-users mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-users
