Hi,
I have a couple old (2.x) PDNS systems still around running the (g)mysql
backends. Both backends are storing the SOA serial as 0. One responds with
an SOA of 0, while the other responds seemingly with autoserial enabled
(most recent change_date for any records). But neither of them have a
doma
On 19/07/2019 16:15, bryantz-p...@zktech.com wrote:
Thank you again for your response, and also thank you for yesterday
pointing me to the support in open policy for the group.
Currently I don't have any evidence as I have not done the packet
captures.
Two of the three outside parties complain
Brian and Alan
Thank you for your responses.
Prior to pulling the record. I ran a test by adding a zone
zone
179.176.183.65.in-addr.arpa
record
179.176.183.65.in-addr.arpa
CNAME 179.160/27.176.183.65.in-addr.arpa
When I dig against our powerdns server I get the expected PTR records
Brian
Thank you again for your response, and also thank you for yesterday pointing me
to the support in open policy for the group.
Currently I don't have any evidence as I have not done the packet captures.
Two of the three outside parties complaining claim their servers look up the
authoritati
On Fri, 2019-07-19 at 14:52 +, bryantz-p...@zktech.com wrote:
> Alan
>
> Where we are getting into issues is that customers we host e-mail
> servers for are having issues as some email service providers appear
> to be forcing their reverse lookups directly against our powerdns
> servers.
>
>
On 19/07/2019 16:00, Brian Candler wrote:
On 19/07/2019 15:52, bryantz-p...@zktech.com wrote:
Where we are getting into issues is that customers we host e-mail
servers for are having issues as some email service providers appear
to be forcing their reverse lookups directly against our powerdns
On 19/07/2019 15:52, bryantz-p...@zktech.com wrote:
Where we are getting into issues is that customers we host e-mail
servers for are having issues as some email service providers appear
to be forcing their reverse lookups directly against our powerdns servers.
Can you provide your evidence fo
On 19/07/2019 13:55, bryantz-p...@zktech.com wrote:
If we do the following dig against our dns server we get a failure...
dig -x 65.183.176.179 @ns1.granddial.net
; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179
@ns1.granddial.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<-
Alan
Where we are getting into issues is that customers we host e-mail servers for
are having issues as some email service providers appear to be forcing their
reverse lookups directly against our powerdns servers. I don't know why they
are doing this, but we get complaints that because we onl
On Fri, 2019-07-19 at 12:55 +, bryantz-p...@zktech.com wrote:
> If we do the following dig against our dns server we get a
> failure...
>
> dig -x 65.183.176.179 @ns1.granddial.net
> ; <<>> DiG 9.9.4-rpz2.13269.14-P2 <<>> -x 65.183.176.179
> @ns1.granddial.net
> ;; global options: +cmd
> ;;
Brian
Thank you for your response.
So what we have in our pdns server is this. zone
zone 160/27.176.183.65.in-addr.arpa
records
160/27.176.183.65.in-addr.arpa
NS ns1.granddial.net
160/27.176.183.65.in-addr.arpa
NS ns2.granddial.net
179.160/27.176.183.65.in-addr.arp
On 19/07/2019 00:02, bryantz-p...@zktech.com wrote:
zone file - 60/27.1.1.1.in-addr.arpa
We then added PTR records for it would looks something like
62.60/27.1.1.1.in-addr.arpa. IN PTR mail.ourserver.net
63.60/27.1.1.1.in-addr.arpa. IN PTR mail.ourotherserver.net
For some reason PowerDNS wil
12 matches
Mail list logo
