<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>Wanted to take a moment and thank everyone for their help &
suggestions on this.<br>
<br>
Apologies for the frantic nature of my prior messages - was trying
to debug too much at once while troubleshooting this. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Cheers,<br>
-Chris<br>
<br>
<br>
<br>
</tt>
<div class="moz-cite-prefix">On 2/18/14 5:11 PM, Chris Moody wrote:<br>
</div>
<blockquote cite="mid:5303DAA1.4080100@node-nine.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<tt>Sorry - my mistake </tt><tt>again re: multiple SOA - </tt><tt>RFC
1034, page 28/29.</tt><tt><br>
</tt><tt><br>
</tt><tt>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.<br>
<br>
The supermaster auto-provision bit worked as the slave shows the
domain in the domains table. Just won't actually axfr the
records.<br>
<br>
</tt><tt>-Chris</tt><br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<br>
<div class="moz-cite-prefix">On 2/18/14 4:51 PM, Chris Moody
wrote:<br>
</div>
<blockquote cite="mid:5303D5F5.6040900@node-nine.com" type="cite">Replies
inline. <br>
<br>
On 2/18/14 2:56 PM, Aki Tuomi wrote: <br>
<blockquote type="cite">On Tue, Feb 18, 2014 at 02:47:33PM
-0500, Chris Moody wrote: <br>
<blockquote type="cite">Could all this perhaps be related to
using opendbx as the backend? <br>
<br>
===== <br>
Feb 18 19:25:22 nyny-dp-1 pdns[7979]: Received NOTIFY for <br>
mysitehealth.com from 206.71.169.116 for which we are not <br>
authoritative <br>
Feb 18 19:25:23 nyny-dp-1 pdns[7979]: Unable to find backend
willing <br>
to host mysitehealth.com for potential supermaster
206.71.169.116. 4 <br>
remote nameservers: <br>
===== <br>
<br>
</blockquote>
This issue is due to misconfiguration for supermasters. The
supermasters table <br>
must have matching hostname and ip address in it. It has to
match ns1.mysitehealth.com and 206.71.169.116. <br>
</blockquote>
<br>
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. <br>
<br>
<blockquote type="cite">
<blockquote type="cite">Here's the brand new zone that's got
the same issue. <br>
===== <br>
mysql> SELECT * FROM records WHERE domain_id = 635; <br>
+-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+
<br>
| id | domain_id | name | type | ttl |
prio | <br>
content | ordername | auth | disabled | <br>
+-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+
<br>
| 35276 | 635 | mysitehealth.com | SOA | 86400 |
NULL | <br>
ns1.mysitehealth.com. <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:postmaster@mysitehealth.com">postmaster@mysitehealth.com</a>
0 10800 3600 <br>
604800 3600 | NULL | NULL | NULL | <br>
| 35277 | 635 | ns1.mysitehealth.com | A | 120 |
NULL | <br>
206.71.169.116 | NULL | NULL | NULL | <br>
| 35278 | 635 | ns2.mysitehealth.com | A | 120 |
NULL | <br>
64.106.186.196 | NULL | NULL | NULL | <br>
| 35279 | 635 | mysitehealth.com | NS | 120 |
NULL | <br>
ns1.mysitehealth.com | NULL | NULL | NULL | <br>
| 35280 | 635 | mysitehealth.com | NS | 120 |
NULL | <br>
ns2.mysitehealth.com | NULL | NULL | NULL | <br>
| 35282 | 635 | mysitehealth.com | MX | 120
| 10 | <br>
mx1.node-nine.com | NULL | NULL | NULL | <br>
+-------+-----------+----------------------+------+-------+------+----------------------------------------------------------------------------+-----------+------+----------+
<br>
6 rows in set (0.00 sec) <br>
<br>
mysql> <br>
===== <br>
<br>
</blockquote>
Can you try dig axfr mysitehealth.com @localhost (if you have
axfr from localhost permitted) <br>
<br>
Please check master logs as well <br>
</blockquote>
So this is strange - I -do- see duplicate SOA records in the
axfr but not in the master's DB. <br>
<br>
ex> <br>
=====[ master ]===== <br>
mysql> SELECT * FROM records WHERE name = "." OR name = ""; <br>
Empty set (0.00 sec) <br>
===== <br>
<br>
=====[ dig axfr @ master ]===== <br>
root@nyny-dp-1 ~ # dig @206.71.169.116 mysitehealth.com axfr <br>
<br>
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
<<>> @206.71.169.116 mysitehealth.com axfr <br>
; (1 server found) <br>
;; global options: +cmd <br>
. 86400 IN SOA ns1.mysitehealth.com.
postmaster.mysitehealth.com. 61 10800 3600 604800 3600 <br>
ns1.mysitehealth.com. 120 IN A 206.71.169.116 <br>
ns2.mysitehealth.com. 120 IN A 64.106.186.196 <br>
mysitehealth.com. 120 IN NS ns1.mysitehealth.com. <br>
mysitehealth.com. 120 IN NS ns2.mysitehealth.com. <br>
mysitehealth.com. 120 IN MX 10 mx1.mysitehealth.com.
<br>
mx1.mysitehealth.com. 120 IN A 206.71.169.116 <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="http://www.mysitehealth.com">www.mysitehealth.com</a>.
120 IN A 206.71.169.116 <br>
. 86400 IN SOA ns1.mysitehealth.com.
postmaster.mysitehealth.com. 61 10800 3600 604800 3600 <br>
;; Query time: 144 msec <br>
;; SERVER: 206.71.169.116#53(206.71.169.116) <br>
;; WHEN: Tue Feb 18 21:40:53 2014 <br>
;; XFR size: 9 records (messages 3, bytes 326) <br>
===== <br>
<br>
Now I suppose it begs the question, why are there duplicate
SOA's being returned when they're not in the DB? <br>
<br>
(I -REALLY- appreciate the help on this) <br>
<br>
-Chris <br>
<blockquote type="cite"> <br>
<blockquote type="cite">Cheers, <br>
-Chris <br>
<br>
On 2/18/14 2:14 PM, Aki Tuomi wrote: <br>
<blockquote type="cite">SELECT * FROM records WHERE
domain_id = <br>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
<br>
_______________________________________________ <br>
Pdns-users mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Pdns-users@mailman.powerdns.com">Pdns-users@mailman.powerdns.com</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mailman.powerdns.com/mailman/listinfo/pdns-users">http://mailman.powerdns.com/mailman/listinfo/pdns-users</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Pdns-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pdns-users@mailman.powerdns.com">Pdns-users@mailman.powerdns.com</a>
<a class="moz-txt-link-freetext" href="http://mailman.powerdns.com/mailman/listinfo/pdns-users">http://mailman.powerdns.com/mailman/listinfo/pdns-users</a>
</pre>
</blockquote>
<br>
</body>
</html>