[Pdns-users] RESOLVED - Re: Need help re: Remote tried to sneak in out-of-zone data ''|SOA during AXFR of zone

Wed Feb 26 21:03:36 UTC 2014

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. postmaster at mysitehealth.com 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 at 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
>> Pdns-users at mailman.powerdns.com
>> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>
>
>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20140226/d2df7c51/attachment-0001.html>