[Pdns-users] Spoof MX records

[Bit World Computing - Michael Mertel]

Hi,

I’am looking for the most efficent way to spoof the answer of a MX query. I 
need to redirect outgoing e-mails (specific domains only) to a smtp gateway for 
further processing before it leaves the local network. I cannot use any kind of 
transport tables at the MTA, so my approach was to use dns therefore.

The number of zones to spoof is currently not defined, could be dozens if not 
hundreds.

I would usually do this kind of stuff with dnsdist (which I love), but would 
the recursor a better choice here?

Thanks for any advice.

—Michael

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

Re: [Pdns-users] PDNS and Isilon Smartconnect Delegation

[Kenneth Marshall]

On Thu, Dec 13, 2018 at 02:17:23PM -0500, Ian Easter wrote:
> Recently switched from BIND9.7.3 to PowerDNS and working through some
> adjustments.
> 
> We previously followed the guidelines for DNS based on the documentation:
> https://www.emc.com/collateral/hardware/white-papers/h8316-wp-smartconnect.pdf
> and everything worked without issue.
> 
> Translating that to PowerDNS seems to be a bit more challenging at the
> moment.
> 
> Adding the same records to PowerDNS are just returning the Isilon SIP A
> address record IP rather then the round robin IP address from the Isilon
> SIP.
> 
> At this point, I'm either looking in the wrong place, wrong keywords, or
> just simply not understanding why this isn't working.
> 
> I did find an old thread regarding this matter but it did not seem to end
> with a resolution.  I had also ran down another thread regarding a similar
> matter which started leading me toward needing to look at configuring
> pdns-recursor for this but I can't get anything to work on either front.
> 
> Greatly appreciate any assistance.
> 
> Current records set on PowerDNS (as they worked on BIND)
> isilon-nfs  NS  isilon-nfs-sip
> isilon-nfs-sip  A   192.168.64.70
> 
> What dig reports
> 
> ; <<>> DiG 9.10.6 <<>> isilon-nfs.teve.inc @10.1.90.52
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15456
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1680
> ;; QUESTION SECTION:
> ;isilon-nfs.teve.inc.   IN  A
> 
> ;; AUTHORITY SECTION:
> isilon-nfs.teve.inc.3600IN  NS  isilon-nfs-sip.teve.inc.
> 
> ;; ADDITIONAL SECTION:
> isilon-nfs-sip.teve.inc. 3600   IN  A   192.168.64.70
> 
> ;; Query time: 18 msec
> ;; SERVER: 10.1.90.52#53(10.1.90.52)
> ;; WHEN: Thu Dec 13 14:14:02 EST 2018
> ;; MSG SIZE  rcvd: 93
> 

Hi Ian,

Using the pdns-recursor, you simply forward-zone the domain to the IP address
of the Isilon DNS service. One nuance that we had to address was that
the  lookups caused problems since we do not have IPv6 so we added a
LUA script to the function preresolve (). Here is what we have:

function preresolve ( remoteip, domain, qtype )

-- Stop bad  record cache problem with Isilon.
if qtype == pdns. and domain == "file-nfs.isilon." then
ret={}
-- pdnslog ("fixing  query for: " .. domain)
-- ret[1]={qtype=pdns., content=""}
return 0, ret
end
end

Once we had that piece everything worked well.

Regards,
Ken
> 
> 
> *Thank you,*
> *Ian Easter*

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

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

Re: [Pdns-users] PDNS and Isilon Smartconnect Delegation

[bert hubert]

On Thu, Dec 13, 2018 at 02:17:23PM -0500, Ian Easter wrote:
> Recently switched from BIND9.7.3 to PowerDNS and working through some
> adjustments.
> 
> We previously followed the guidelines for DNS based on the documentation:
> https://www.emc.com/collateral/hardware/white-papers/h8316-wp-smartconnect.pdf
> and everything worked without issue.

Hi Ian,

We happen to have a quorum of people with Isilon expertise present on our
IRC channel right now. Could you drop by? 
https://www.powerdns.com/opensource.html
has a link to a web client.

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

[Pdns-users] PDNS and Isilon Smartconnect Delegation

[Ian Easter]

Recently switched from BIND9.7.3 to PowerDNS and working through some
adjustments.

We previously followed the guidelines for DNS based on the documentation:
https://www.emc.com/collateral/hardware/white-papers/h8316-wp-smartconnect.pdf
and everything worked without issue.

Translating that to PowerDNS seems to be a bit more challenging at the
moment.

Adding the same records to PowerDNS are just returning the Isilon SIP A
address record IP rather then the round robin IP address from the Isilon
SIP.

At this point, I'm either looking in the wrong place, wrong keywords, or
just simply not understanding why this isn't working.

I did find an old thread regarding this matter but it did not seem to end
with a resolution.  I had also ran down another thread regarding a similar
matter which started leading me toward needing to look at configuring
pdns-recursor for this but I can't get anything to work on either front.

Greatly appreciate any assistance.

Current records set on PowerDNS (as they worked on BIND)
isilon-nfs  NS  isilon-nfs-sip
isilon-nfs-sip  A   192.168.64.70

What dig reports

; <<>> DiG 9.10.6 <<>> isilon-nfs.teve.inc @10.1.90.52
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15456
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;isilon-nfs.teve.inc.   IN  A

;; AUTHORITY SECTION:
isilon-nfs.teve.inc.3600IN  NS  isilon-nfs-sip.teve.inc.

;; ADDITIONAL SECTION:
isilon-nfs-sip.teve.inc. 3600   IN  A   192.168.64.70

;; Query time: 18 msec
;; SERVER: 10.1.90.52#53(10.1.90.52)
;; WHEN: Thu Dec 13 14:14:02 EST 2018
;; MSG SIZE  rcvd: 93



*Thank you,*
*Ian Easter*
___
Pdns-users mailing list
Pdns-users@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/pdns-users

Re: [Pdns-users] Unable to resolve domain when using DO and not AD

[Frank Louwers via Pdns-users]

Dear Luca,


> On 12 Dec 2018, at 19:53, Luca Lesinigo  > wrote:
> 
> Il giorno 12 dic 2018, alle ore 18:45, bert hubert  > ha scritto:
>>> Right now I am refraining to disclose the domain because I don’t know if
>>> this behavior could disclose a software/version/configuration with some
>>> kind of known vulnerability.
>> Sadly, that is where we stop reading about your problem.
>> Please see 
>> https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ 
>> 
> 

…

> I don’t know and don’t want to find out if there is any legal aspect about 
> disclosing a potential vulnerability in someone else’s systems, especially 
> since we are in the same country and the other party is a much bigger company 
> than ours - they can keep being unresolvable by all powerdns (and possibly 
> others) recursors in the world as far as I’m concerned. 

I completely understand your position, but your are doing the PowerDNS 
community a disservice.

To illustrate that, let me cut from your previous email:

> The same domain results in "All Queries to dns1.domain.tld for domain.tld/A 
> timed out or failed” when trying with Verisign Labs DNSSEC Analyzer ( 
> https://dnssec-analyzer.verisignlabs.com/ 
>  )
> Public dns services (I tried Cloudflare and Google) do resolve correctly that 
> domain, my guess is that they are doing queries with different flags and/or 
> that they have some kind of workaround for this specific defect.

So I see two things here:

1) As the VerisignLabs analyser complains about the domain, there is a 
misconfiguration with the domain name in question. It does not comply to all 
DNSSec standards, as interpreted by Verisign labs and (as your PowerDNS 
Recursor won’t resolve it), but PowerDNS’ interpretation. 

2) Yet some other resolvers (CF and Google to name a few) are capable to work 
around this issue.

So while it might be a misconfiguration or maybe a bug at the other end, it is 
important for the PowerDNS Community. If we could do two important things:

a) we could investigate, try a few things, find out why the domain is behaving 
that way and see if there is a way this could be dealt with. Maybe it is a 
misconfig/bug at the other end, maybe it’s just a different interpretation of 
some dnssec standard that’s not 100% completely well described in the RFCs. So 
if you tell us the domain name, we might be able to fix the bug, or work around 
the issue if needed. Result: You’ve made the PowerDNS Community happy and 
making PowerDNS better software than it already is!

b) DNS operators are friendly people most of the time. There are various ways 
to contact them. If one of your domain names would fail to be resolved by a 
rather large chunk of the Internet, wouldn’t you want to know?  Result: You’ve 
made the Internet a better place

As the domain name servers in question are “live” on the Internet, and there’s 
very little chance this will lead to something “the bad guys” are able to 
exploit, it’s a configuration issue more than it is a security issue. So 
please, consider telling us the domain name in question, as that’s the only way 
to make the internet a better place.

Regards,

Frank

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