[Pdns-users] install version 3.4.5 on Ubuntu 16.04

[Seyed Hossein Mortazavi]

I need to install pdns-server and pdns-backend-mysql 3.4.5 on Ubuntu 16.04.
If I use the following command:

sudo apt-get install pdns-backend-mysql
then version 4 will be installed. I need version 3.4.5

Also this also won't work:

sudo apt-get install pdns-backend-mysql=3.4.5
(other combinations such as 3.4.5-1build2_amd64 also don't work).

I can find the package here:
https://launchpad.net/ubuntu/xenial/amd64/pdns-backend-mysql/3.4.5-1build2

But if I download it and use dpkg -i to install it with apt-get -f install,
then it would still install version 4.

*Unpacking pdns-backend-mysql (4.0.3-1pdns.xenial) over (3.4.5-1build2)*

Does anyone know what I need to do?


-- 
Hossein
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DiG: Hopefully Final Thoughts..

[stancs3]

Many thanks for your comprehensive replies.

I have a number of paths to explore now and will head off to do some
more careful testing.

If I need further advice I will make sure to include a better set of
test results.

I certainly have more confidence in getting to a solution that works
for me, given the support of this forum.

Stan


On Fri, 2017-02-17 at 08:15 +, Brian Candler wrote:
> On 17/02/2017 06:45, stancs3 wrote:
> > 
> > Reverse doesn't work in this config, so I figure on giving up on
> > recursor.
> What do you mean by "reverse doesn't work"? Can you give a specific 
> example of what you did, what you saw, and what you expected to see?
> 
> Reverse is just another domain (under in-addr.arpa), no different to
> any 
> other.
> > 
> > I can either use my router's recursor, or perhaps set up a pdns-
> > recursor on a different VM to keep it clean. Wouldn't that be the
> > same/better than the router's?
> Most routers' built-in DNS is pretty poor - little more than a
> caching 
> forwarder to an upstream DNS (like dnsmasq), so having your own 
> pdns-recursor is likely to be much better.
> 
> If you want your authoritative DNS to be visible to the outside
> world 
> for real delegation, then it needs to listen on port 53. If you want 
> your recursive DNS to be usable by local clients, then it also needs
> to 
> listen on port 53, since most clients can't be (easily) configured
> to 
> send their DNS queries to a different port.
> 
> So, to run both auth and recursive, you need to assign two IP
> addresses. 
> Those can either be two different VMs (maximum separation), two 
> different containers, or even two different IPs in the same machine, 
> where the pns-auth and pdns-recursor processes are configured to bind
> to 
> (listen on) a different individual IP address.
> 
> You could try fancy tricks with dns-dist in front, but personally
> I'd 
> just go for the two VMs or two containers.
> 
> Don't forget redundancy. For authoritative DNS you'll want another 
> nameserver on a completely different backbone (see RFC2182). For
> client 
> redundancy, two local recursors is what you want.
> 
> HTH,
> 
> Brian.
> 
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Brian Candler]

On 17/02/2017 13:29, Thomas Mieslinger wrote:

dig asie4all.com. @192.43.172.30

; <<>> DiG 9.10.4-P5 <<>> asie4all.com. @192.43.172.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;asie4all.com.INA

;; AUTHORITY SECTION:
asie4all.com.172800INNSmx1.ovh.net.
asie4all.com.172800INNSmx2.ovh.net.

;; ADDITIONAL SECTION:
mx1.ovh.net.172800INA213.186.33.29
mx2.ovh.net.172800INA213.186.33.45 



That's not what I see from here. Maybe this domain just got fed up and 
moved away from using OVH.


$ dig asie4all.com. @192.43.172.30

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> asie4all.com. @192.43.172.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53672
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;asie4all.com.INA

;; AUTHORITY SECTION:
asie4all.com.172800INNSns-fr.1and1-dns.fr.
asie4all.com.172800INNSns-fr.1and1-dns.biz.
asie4all.com.172800INNSns-fr.1and1-dns.com.
asie4all.com.172800INNSns-fr.1and1-dns.org.

;; ADDITIONAL SECTION:
ns-fr.1and1-dns.com.172800IN 2001:8d8:fe:53:0:d9a0:5204:100
ns-fr.1and1-dns.com.172800INA217.160.82.4

;; Query time: 13 msec
;; SERVER: 192.43.172.30#53(192.43.172.30)
;; WHEN: Fri Feb 17 16:14:46 2017
;; MSG SIZE  rcvd: 202


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[bert hubert]

On Fri, Feb 17, 2017 at 02:33:37PM +0100, Peter van Dijk wrote:
> >Call me confused, but it happened every day this week.
> 
> Because OVH put those records in the .net zone. OVH did this. OVH needs to
> fix this. There is no ‘security issue’, there is no ‘CVE needed’. There is
> just OVH that needs to fix these records.

And to really finalise this discussion, PowerDNS could of course utilize a
split cache to segregate glue from actual data.  This would however likely
again break other things, and we'd be doing that to benefit operators
putting wrong data in DNS.

In this case, the .NET servers told us about data in .NET and we believed
the .NET servers. That data was put in the .NET zone by OVH and as a result
OVH email delivery stopped working. 

Way back when in January 1980, Jon Postel wrote in RFC791:

"In general, an implementation should be conservative in its sending
 behavior, and liberal in its receiving behavior."

This sentence has guided a lot of resolver development where BIND, Unbound,
Knot resolver and PowerDNS etc accept a Lot of broken stuff in the interest
of keeping the internet working. 

Less frequently quoted is the second part of that paragraph from RFC 791:

"That is, it should be careful to send well-formed datagrams, but should
 accept any datagram that it can interpret (e.g., not object to technical
 errors where the meaning is still clear)."

This looks decidedly worse. This does not look like decent design. In the
OVH case, I'm not even sure that "the meaning is still clear" if you publish
two different IP addresses for a name. Which is right?

In 2015, Martin Thomson wrote an Internet Draft "The Harmful
Consequences of Postel's Maxim".  In this draft, he argues that the
'robustness principle' actually causes protocol decay:

"An implementation that reacts to variations in the manner advised by
 Postel sets up a feedback cycle:

   o  Over time, implementations progressively add new code to constrain
  how data is transmitted, or to permit variations what is received.

   o  Errors in implementations, or confusion about semantics can
  thereby be masked.

   o  As a result, errors can become entrenched, forcing other
  implementations to be tolerant of those errors."

[https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00]

What you are doing in your emails is asking us to do take further steps in
this protocol decay, to benefit the people sending wrong data.

And for now, we have better things to do. 

Bert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Peter van Dijk]

Hello Thomas,

this will be my last email. I am tired of dealing with your stubborn 
confusion.


On 17 Feb 2017, at 14:29, Thomas Mieslinger wrote:

I clear the old mx0..5.ovh.net A records from recursor caches, a 
customer sends an email to bureauxdeventepro.com, the 213.186.33.XX 
ips get the new default answer for mxX.ovh.net.


Call me confused, but it happened every day this week.


Because OVH put those records in the .net zone. OVH did this. OVH needs 
to fix this. There is no ‘security issue’, there is no ‘CVE 
needed’. There is just OVH that needs to fix these records.


Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

Hello Peter,

On 17.02.17 14:17, Peter van Dijk wrote:

Hello Thomas,

On 17 Feb 2017, at 14:15, Thomas Mieslinger wrote:

On 17.02.17 13:56, Brian Candler wrote:

On 17/02/2017 12:53, Thomas Mieslinger wrote:

With crafted glue in the tld zone and mailrelays using pdns_recursor
you could redirect mail traffic.


If you have the ability to craft glue in the tld zone, surely you could
also just change the delegation outright??


No, the idea is to create a new domain with malicious glue and then
send emails over the MXes to infiltrate. The MXes will do lookups,
which trigger the pdns_recursor cache poisoning.


You are confused. This is impossible.


Based on what I have seen in the past days the following happens:

I clear the old mx0..5.ovh.net A records from recursor caches, a 
customer sends an email to bureauxdeventepro.com, the 213.186.33.XX ips 
get the new default answer for mxX.ovh.net.


Call me confused, but it happened every day this week.


My employers customers called in because they couldn't send emails to
ovh MXes. If the broken domains would have been malicious and glue ips
with port 25 open, the MXes would have delivered the emails to them.


It would be very dumb of OVH to put malicious hosts in there. Why would
they do such a thing?


So do registries accept something like "mx00.t-online.de A
64.233.187.26" as hostobject for a NS of a domain?


No.


In the case of .com/.net I have the feeling they accept all kind of
bullshit (see first mail of this thread)


No, they don’t. Only ovh.net can make hosts under ovh.net.


Not really. At least another registrar can reuse host objects.

Cleared earlier this week:

dig asie4all.com. @192.43.172.30

; <<>> DiG 9.10.4-P5 <<>> asie4all.com. @192.43.172.30
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4893
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;asie4all.com.  IN  A

;; AUTHORITY SECTION:
asie4all.com.   172800  IN  NS  mx1.ovh.net.
asie4all.com.   172800  IN  NS  mx2.ovh.net.

;; ADDITIONAL SECTION:
mx1.ovh.net.172800  IN  A   213.186.33.29
mx2.ovh.net.172800  IN  A   213.186.33.45

;; Query time: 9 msec
;; SERVER: 192.43.172.30#53(192.43.172.30)
;; WHEN: Wed Feb 15 09:42:50 CET 2017
;; MSG SIZE  rcvd: 116
whois asie4all.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: ASIE4ALL.COM
   Registrar: 1&1 INTERNET SE
   Sponsoring Registrar IANA ID: 83
   Whois Server: whois.1and1.com
   Referral URL: http://registrar.1and1.info
   Name Server: MX1.OVH.NET
   Name Server: MX2.OVH.NET
   Status: clientTransferProhibited 
https://icann.org/epp#clientTransferProhibited

   Updated Date: 02-feb-2017
   Creation Date: 29-jan-2017
   Expiration Date: 29-jan-2018

>>> Last update of whois database: Wed, 15 Feb 2017 08:48:18 GMT <<<
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Peter van Dijk]

Hello Thomas,

On 17 Feb 2017, at 14:15, Thomas Mieslinger wrote:


On 17.02.17 13:56, Brian Candler wrote:

On 17/02/2017 12:53, Thomas Mieslinger wrote:

With crafted glue in the tld zone and mailrelays using pdns_recursor
you could redirect mail traffic.

If you have the ability to craft glue in the tld zone, surely you 
could

also just change the delegation outright??


No, the idea is to create a new domain with malicious glue and then 
send emails over the MXes to infiltrate. The MXes will do lookups, 
which trigger the pdns_recursor cache poisoning.


You are confused. This is impossible.

My employers customers called in because they couldn't send emails to 
ovh MXes. If the broken domains would have been malicious and glue ips 
with port 25 open, the MXes would have delivered the emails to them.


It would be very dumb of OVH to put malicious hosts in there. Why would 
they do such a thing?


So do registries accept something like "mx00.t-online.de A 
64.233.187.26" as hostobject for a NS of a domain?


No.

In the case of .com/.net I have the feeling they accept all kind of 
bullshit (see first mail of this thread)


No, they don’t. Only ovh.net can make hosts under ovh.net.

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

On 17.02.17 13:56, Brian Candler wrote:

On 17/02/2017 12:53, Thomas Mieslinger wrote:

With crafted glue in the tld zone and mailrelays using pdns_recursor
you could redirect mail traffic.


If you have the ability to craft glue in the tld zone, surely you could
also just change the delegation outright??


No, the idea is to create a new domain with malicious glue and then send 
emails over the MXes to infiltrate. The MXes will do lookups, which 
trigger the pdns_recursor cache poisoning.


My employers customers called in because they couldn't send emails to 
ovh MXes. If the broken domains would have been malicious and glue ips 
with port 25 open, the MXes would have delivered the emails to them.


So do registries accept something like "mx00.t-online.de A 
64.233.187.26" as hostobject for a NS of a domain?


In the case of .com/.net I have the feeling they accept all kind of 
bullshit (see first mail of this thread)


Cheers
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Brian Candler]

On 17/02/2017 12:53, Thomas Mieslinger wrote:
With crafted glue in the tld zone and mailrelays using pdns_recursor 
you could redirect mail traffic.


If you have the ability to craft glue in the tld zone, surely you could 
also just change the delegation outright??


___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

Hi Pieter,

On 17.02.17 12:34, Pieter Lexis wrote:

On Fri, 17 Feb 2017 11:39:51 +0100
Thomas Mieslinger  wrote:


Why trusts pdns_recursor records from answers without aa bit set?


While resolving, this is the only thing we can trust. And this answer is cached 
as well. This speeds things up tremendously.
We could try to be more resilient against this when retrieving this information 
from the cache, but we do not blindly trust additional information.


I was unable to reproduce this with 4.0.4 so I don't see the need to try 
to get a CVE on this.


Why?

With crafted glue in the tld zone and mailrelays using pdns_recursor you 
could redirect mail traffic.


Maybe you could reevaluate your opinion on caching non aa bit set records.

Of course dnssec solves this, but it is still a long way until all zones 
are signed.


Thomas
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Pieter Lexis]

Hi Thoomas,

On Fri, 17 Feb 2017 11:39:51 +0100
Thomas Mieslinger  wrote:

> Why trusts pdns_recursor records from answers without aa bit set?

While resolving, this is the only thing we can trust. And this answer is cached 
as well. This speeds things up tremendously.
We could try to be more resilient against this when retrieving this information 
from the cache, but we do not blindly trust additional information.

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

On 17.02.17 10:58, bert hubert wrote:

On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:

I understand that this must have a performance impact but having the choice
between 1000s of customer calls a day "I can't send emails to ovh and it is
your fault" and buying some more recursor boxes, I clearly want more
recursor boxes and less disappointed customers.


The disappointed customers may want to ask OVH why it is publishing the
wrong IP addresses?


Why trusts pdns_recursor records from answers without aa bit set?

Thomas
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

On 17.02.17 11:14, Aki Tuomi wrote:

On 17.02.2017 12:11, Thomas Mieslinger wrote:

On 17.02.17 10:58, bert hubert wrote:

On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:

ovh changed its MX A records and now my employers Mail relays can't

> [..]

Those additional records are placed there by the owner of the name(s).


Yes.

As you can see in example, invalid data can be used.

Over the past 20 year verisign refused to check data (like .de and .fr 
do) because customers don't want to see error messages. customers are 
always right and know what they are doing.


And versign adds glue where it is not needed (a .com domain with .net 
nameservers does not need glue.)



~$ whois dns103.ovh.net

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.


> [..]


So the owner can fix it, or request gandi to fix it.


Can I get the .com and the .net zone file please. That would speed up 
the process enormously.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

On 17.02.17 11:01, Nico CARTRON wrote:

On 17/02/2017 10:58, bert hubert wrote:

On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:

ovh changed its MX A records and now my employers Mail relays can't send
email to ovh.

Have you attempted to talk to OVH about their misconfiguration?
 [..]
And so the code in resolvers becomes ever more a set of exceptions and
workarounds. And please know, every workaround breaks something else.

So please ask OVH to fix their stuff.

Agreed, they usually are very responsive, either by email or Twitter.



http://travaux.ovh.net/?do=details=22948

Again, it is glue from the tld zone file. OVH can't fix it, I can't fix it.

It is unlikely that I can motivate verisign to run a big sed on the .com 
and .net zone file.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Aki Tuomi]

On 17.02.2017 12:11, Thomas Mieslinger wrote:
> On 17.02.17 10:58, bert hubert wrote:
>> On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:
>>> ovh changed its MX A records and now my employers Mail relays can't
>>> send
>>> email to ovh.
>>
>> Have you attempted to talk to OVH about their misconfiguration?
>
> There is no misconfiguration at ovh.
>
>> I ask this because the DNS Resolver community keeps getting asked to
>> solve
>> problems which are not ours. But it is easier to ask us to change.
>>
>> We (BIND, Unbound) keep running into broken F5 configurations for
>> example,
>> and yes, we can fix those with some special casing. But people always
>> ask us
>> because we are easier to talk to than the operators of the F5 machines.
>
> In my experience operating F5 gtm is hard... ( but that is completely
> of topic.)
>
>> And so the code in resolvers becomes ever more a set of exceptions and
>> workarounds. And please know, every workaround breaks something else.
>>
>> So please ask OVH to fix their stuff.
>
> They can't.
>
> If verisign had a policy like denic or .fr, this mess would not be in
> the tld zone file.
>
>>> Many many domains are wrongly delegated with wrong glue records in
>>> the tld
>>> zone.
>>
>> Let us not encourage broken things to work well. Some pain is quite
>> motivational to clean this up.
>
> The pain is only felt by people who can't fix it.
>
>>> I understand that this must have a performance impact but having the
>>> choice
>>> between 1000s of customer calls a day "I can't send emails to ovh
>>> and it is
>>> your fault" and buying some more recursor boxes, I clearly want more
>>> recursor boxes and less disappointed customers.
>>
>> The disappointed customers may want to ask OVH why it is publishing the
>> wrong IP addresses?
>
> It is not ovh publishing wrong A records, it is glue from the tld zone.
>
> The example domain is register with gandi.net, so gandi or their
> customer would need to update NS Records and glue. I can't fix it, ovh
> can't fix it.
>
>

Those additional records are placed there by the owner of the name(s).

~$ whois dns103.ovh.net

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Server Name: DNS103.OVH.NET
   IP Address: 213.251.188.147
   IP Address: 2001:41D0:1:4A93:0:0:0:1
   Registrar: OVH
   Whois Server: whois.ovh.com
   Referral URL: http://www.ovh.com


   Server Name: DNS103.OVH.NET.VITABAT.FR
   Registrar: OVH
   Whois Server: whois.ovh.com
   Referral URL: http://www.ovh.com


So the owner can fix it, or request gandi to fix it.

Aki
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

On 17.02.17 10:58, bert hubert wrote:

On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:

ovh changed its MX A records and now my employers Mail relays can't send
email to ovh.


Have you attempted to talk to OVH about their misconfiguration?


There is no misconfiguration at ovh.


I ask this because the DNS Resolver community keeps getting asked to solve
problems which are not ours. But it is easier to ask us to change.

We (BIND, Unbound) keep running into broken F5 configurations for example,
and yes, we can fix those with some special casing. But people always ask us
because we are easier to talk to than the operators of the F5 machines.


In my experience operating F5 gtm is hard... ( but that is completely of 
topic.)



And so the code in resolvers becomes ever more a set of exceptions and
workarounds. And please know, every workaround breaks something else.

So please ask OVH to fix their stuff.


They can't.

If verisign had a policy like denic or .fr, this mess would not be in 
the tld zone file.



Many many domains are wrongly delegated with wrong glue records in the tld
zone.


Let us not encourage broken things to work well. Some pain is quite
motivational to clean this up.


The pain is only felt by people who can't fix it.


I understand that this must have a performance impact but having the choice
between 1000s of customer calls a day "I can't send emails to ovh and it is
your fault" and buying some more recursor boxes, I clearly want more
recursor boxes and less disappointed customers.


The disappointed customers may want to ask OVH why it is publishing the
wrong IP addresses?


It is not ovh publishing wrong A records, it is glue from the tld zone.

The example domain is register with gandi.net, so gandi or their 
customer would need to update NS Records and glue. I can't fix it, ovh 
can't fix it.



___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Nico CARTRON]

On 17/02/2017 10:58, bert hubert wrote:

On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:

ovh changed its MX A records and now my employers Mail relays can't send
email to ovh.

Have you attempted to talk to OVH about their misconfiguration?

I ask this because the DNS Resolver community keeps getting asked to solve
problems which are not ours. But it is easier to ask us to change.

We (BIND, Unbound) keep running into broken F5 configurations for example,
and yes, we can fix those with some special casing. But people always ask us
because we are easier to talk to than the operators of the F5 machines.

And so the code in resolvers becomes ever more a set of exceptions and
workarounds. And please know, every workaround breaks something else.

So please ask OVH to fix their stuff.

Agreed, they usually are very responsive, either by email or Twitter.

--
Nico
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[bert hubert]

On Fri, Feb 17, 2017 at 10:49:08AM +0100, Thomas Mieslinger wrote:
> ovh changed its MX A records and now my employers Mail relays can't send
> email to ovh.

Have you attempted to talk to OVH about their misconfiguration?

I ask this because the DNS Resolver community keeps getting asked to solve
problems which are not ours. But it is easier to ask us to change.

We (BIND, Unbound) keep running into broken F5 configurations for example,
and yes, we can fix those with some special casing. But people always ask us
because we are easier to talk to than the operators of the F5 machines.

And so the code in resolvers becomes ever more a set of exceptions and
workarounds. And please know, every workaround breaks something else. 

So please ask OVH to fix their stuff. 

> Many many domains are wrongly delegated with wrong glue records in the tld
> zone. 

Let us not encourage broken things to work well. Some pain is quite
motivational to clean this up.

> I understand that this must have a performance impact but having the choice
> between 1000s of customer calls a day "I can't send emails to ovh and it is
> your fault" and buying some more recursor boxes, I clearly want more
> recursor boxes and less disappointed customers.

The disappointed customers may want to ask OVH why it is publishing the
wrong IP addresses?

Bert
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

[Pdns-users] pdns_recursors trusts addtional section where it better shouldn't

[Thomas Mieslinger]

Hi,

ovh changed its MX A records and now my employers Mail relays can't send 
email to ovh.


This may sound unrelated to pdns_recursor but please read on:

Many many domains are wrongly delegated with wrong glue records in the 
tld zone. As of 2017-02-17 10:43:00 CET dig produces the following output:


dig @i.gtld-servers.net. bureauxdeventepro.com

; <<>> DiG 9.10.4-P5 <<>> @i.gtld-servers.net. bureauxdeventepro.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33279
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 8
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bureauxdeventepro.com. IN  A

;; AUTHORITY SECTION:
bureauxdeventepro.com.  172800  IN  NS  mx4.ovh.net.
bureauxdeventepro.com.  172800  IN  NS  mx1.ovh.net.
bureauxdeventepro.com.  172800  IN  NS  mxb.ovh.net.
bureauxdeventepro.com.  172800  IN  NS  dns103.ovh.net.
bureauxdeventepro.com.  172800  IN  NS  ns103.ovh.net.

;; ADDITIONAL SECTION:
mx4.ovh.net.172800  IN  A   213.186.33.74
mx1.ovh.net.172800  IN  A   213.186.33.29
mxb.ovh.net.172800  IN  A   213.186.37.81
dns103.ovh.net. 172800  IN  2001:41d0:1:4a93::1
dns103.ovh.net. 172800  IN  A   213.251.188.147
ns103.ovh.net.  172800  IN  2001:41d0:1:1993::1
ns103.ovh.net.  172800  IN  A   213.251.128.147

;; Query time: 9 msec
;; SERVER: 192.43.172.30#53(192.43.172.30)
;; WHEN: Fri Feb 17 10:43:40 CET 2017
;; MSG SIZE  rcvd: 288

The real IP address for mx1.ovh.net is 137.74.125.138. How can I make 
pdns_recursor to not store records from the additional section in the 
caches?


I understand that this must have a performance impact but having the 
choice between 1000s of customer calls a day "I can't send emails to ovh 
and it is your fault" and buying some more recursor boxes, I clearly 
want more recursor boxes and less disappointed customers.


Cheers Thomas
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DiG: Hopefully Final Thoughts..

[Brian Candler]

On 17/02/2017 06:45, stancs3 wrote:

Reverse doesn't work in this config, so I figure on giving up on
recursor.
What do you mean by "reverse doesn't work"? Can you give a specific 
example of what you did, what you saw, and what you expected to see?


Reverse is just another domain (under in-addr.arpa), no different to any 
other.

I can either use my router's recursor, or perhaps set up a pdns-
recursor on a different VM to keep it clean. Wouldn't that be the
same/better than the router's?


Most routers' built-in DNS is pretty poor - little more than a caching 
forwarder to an upstream DNS (like dnsmasq), so having your own 
pdns-recursor is likely to be much better.


If you want your authoritative DNS to be visible to the outside world 
for real delegation, then it needs to listen on port 53. If you want 
your recursive DNS to be usable by local clients, then it also needs to 
listen on port 53, since most clients can't be (easily) configured to 
send their DNS queries to a different port.


So, to run both auth and recursive, you need to assign two IP addresses. 
Those can either be two different VMs (maximum separation), two 
different containers, or even two different IPs in the same machine, 
where the pns-auth and pdns-recursor processes are configured to bind to 
(listen on) a different individual IP address.


You could try fancy tricks with dns-dist in front, but personally I'd 
just go for the two VMs or two containers.


Don't forget redundancy. For authoritative DNS you'll want another 
nameserver on a completely different backbone (see RFC2182). For client 
redundancy, two local recursors is what you want.


HTH,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] DiG: more success but puzzling

[Brian Candler]

On 17/02/2017 06:10, stancs3 wrote:

OK, I managed to get DiG to respond with A records, but only by
specifying the hostname in from of the domain name. This is OK, but
when the servers where reversed, a simple DiG NS would return the NS
records,*and*  the A records.

Again not a showstopper unless it points to config still broken.


Do you mean that "dig foo" returns NXDOMAIN, but "ping foo" works 
(resolving foo to the A record for foo.example.com)?


That's correct behaviour, and you should find it works if you do "dig 
+search foo"


By default, the dig client by default does not use the search list in 
/etc/resolv.conf, but normal DNS clients do.


nameserver x.x.x.x
search example.com

# Means: if I can't resolve foo them try adding example.com to the end

If you were able to do "dig foo" and got the answer previously, that 
means your original nameserver configuration was completely broken - it 
was answering queries for top-level name "foo." with data from elsewhere 
in the DNS tree.  So this is a good sign that you fixed things.


Pointing clients at the recursor, and having the recursor forward 
specific domains to your internal authoritative DNS, is the right way to 
do this.


Regards,

Brian.

___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users