On 2014-09-01 Mon 08:58 AM |, Arthur Mesh wrote:
I have the same exact symptom, unbound.conf:
local-zone: 10.in-addr.arpa. nodefault
Change this to:
local-zone: 10.in-addr.arpa typetransparent
See types under the section 'local-zone' of unbound.conf(5)
On Sun, Jul 27, 2014 at 11:20:43AM +0200, Patrik Lundin wrote:
How is/was the reverse zone configured in nsd? I am currently trying to
debug an issue i've seen when the stub-zone in unbound is wider (name:
10.in-addr.arpa) than the zone in nsd (name: 0.0.10.in-addr.arpa).
To me the following
On Mon, Sep 01, 2014 at 08:58:11AM -0700, Arthur Mesh wrote:
I have no good explanation as to what's going on. I've tried this on current
(as opposed to 5.5), and issue does NOT go away.
I decided to ask about this on unbound-users:
On Monday, September 1, 2014 17:58 CEST, Arthur Mesh arthurm...@gmail.com
wrote:
On Sun, Jul 27, 2014 at 11:20:43AM +0200, Patrik Lundin wrote:
How is/was the reverse zone configured in nsd? I am currently trying to
debug an issue i've seen when the stub-zone in unbound is wider (name:
On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote:
On Saturday, July 26, 2014 17:35 CEST, Sonic sonicsm...@gmail.com wrote:
On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote:
If you're just using a /24 as your access-control seems to indicate
try
On Sunday, July 27, 2014 11:20 CEST, Patrik Lundin
patrik.lundin@gmail.com wrote:
On Sat, Jul 26, 2014 at 07:34:16PM +0200, Sebastian Reitenbach wrote:
On Saturday, July 26, 2014 17:35 CEST, Sonic sonicsm...@gmail.com wrote:
On Sat, Jul 26, 2014 at 11:21 AM, Sonic
On Sun, Jul 27, 2014 at 5:20 AM, Patrik Lundin
patrik.lundin@gmail.com wrote:
My understanding is that transparent is used when you want to override
certain records in a zone with local-data configured in unbound.conf.
Given that you have no such things in the pasted configuration
On Sun, Jul 27, 2014 at 10:42:57AM -0400, Sonic wrote:
From the man page:
You can also selectively unblock a part of the zone by making that
part transparent with a local-zone statement. This also works with the
other default zones.
Ah, nice catch!
So if you're prepared to answer
On Sun, Jul 27, 2014 at 12:27:54PM +0200, Sebastian Reitenbach wrote:
My understanding is that transparent is used when you want to override
certain records in a zone with local-data configured in unbound.conf.
Given that you have no such things in the pasted configuration
nodefault is
Following up on this thread given the mention it got in the recent
unbound question:
On Sat, May 17, 2014 at 08:04:32PM +0200, Sebastian Reitenbach wrote:
# the stub zones I want to resolve via nsd on localhost
stub-zone:
name: ds9
stub-addr: 127.0.0.1@5353
stub-zone:
On Sat, May 17, 2014 at 2:04 PM, Sebastian Reitenbach
sebas...@l00-bugdead-prods.de wrote:
local-zone: 10.in-addr.arpa. nodefault
If you're just using a /24 as your access-control seems to indicate
try replacing the above with (this works great for me):
local-zone: 0.0.10.in-addr.arpa.
On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote:
If you're just using a /24 as your access-control seems to indicate
try replacing the above with (this works great for me):
local-zone: 0.0.10.in-addr.arpa. transparent
and update the stub-zone name to read:
name:
On Saturday, July 26, 2014 17:35 CEST, Sonic sonicsm...@gmail.com wrote:
On Sat, Jul 26, 2014 at 11:21 AM, Sonic sonicsm...@gmail.com wrote:
If you're just using a /24 as your access-control seems to indicate
try replacing the above with (this works great for me):
local-zone:
Hi,
I'm new to nsd/unbound, and maybe I did something wrong, however:
I run i386 snapshot, with nsd/unbound on the same host.
NSD listening on port 5353 is authoritative for 1 forward zone, and two
reverse zones, one IPv4 private addresses, and another IPv6 zone.
The forward zone, and the
On Fri, Dec 06, 2013 at 08:35:52PM +0100, Patrik Lundin wrote:
Given the +trace output you supplied that address is not part of the
trail from the DNS root, and in that case the only involvement is
answering the initial equivalent of dig @216.146.35.35 . NS.
For the archives:
That should
Turns out the problem was with the Internet Guide service. If the IP
address from which the query was sent was on the subscriber list then
the incorrect info was sent. That's why it worked from one of my
networks but not the others.
Thanks to all.
Chris
This falls under the category When in doubt, ask the OpenBSD guys
(and as all of my firewalls are running OpenBSD I hope this isn't too
off topic).
Basically, four of my networks are not getting an answer for a
specific mx query from dyn.com's DNS server. Yet every other DNS cache
I've queried
Chris Smith obsd_m...@chrissmith.org writes:
Basically, four of my networks are not getting an answer for a
specific mx query from dyn.com's DNS server.
but, say
$ dig @216.146.35.35 bsdly.net mx
works?
Or do you get no answer for any queries?
- Peter
--
Peter N. M. Hansteen, member of
On Fri, Dec 6, 2013 at 11:54 AM, Peter N. M. Hansteen pe...@bsdly.net wrote:
but, say
$ dig @216.146.35.35 bsdly.net mx
works?
Or do you get no answer for any queries?
It's just that one particular query and the same domain's TXT record.
There may be others but this one was found because
Em 06-12-2013 14:31, Chris Smith escreveu:
This falls under the category When in doubt, ask the OpenBSD guys
(and as all of my firewalls are running OpenBSD I hope this isn't too
off topic).
Basically, four of my networks are not getting an answer for a
specific mx query from dyn.com's DNS
On Fri, Dec 6, 2013 at 12:07 PM, Giancarlo Razzolini
grazzol...@gmail.com wrote:
I do not know if it is the case, but many isp's today use dns
transparent proxying.
You can try using the site www.dnsleaktest.com to see if it is your
case.
The lwtitle.com mx and lwtitle.com txt queries
Em 06-12-2013 15:42, Chris Smith escreveu:
The lwtitle.com mx and lwtitle.com txt queries both fail for me here
and I run unbound as a resolver on my firewall and I pass the DNS leak
test.
The dns leaktest only detects if the provider is actively redirecting
your queries to their caching
On Fri, Dec 06, 2013 at 12:42:09PM -0500, Chris Smith wrote:
The lwtitle.com mx and lwtitle.com txt queries both fail for me here
and I run unbound as a resolver on my firewall and I pass the DNS leak
test.
Just out of curiosity: If you are running unbound on the firewall, why
are you
On Fri, Dec 6, 2013 at 1:38 PM, Patrik Lundin
patrik.lundin@gmail.com wrote:
Just out of curiosity: If you are running unbound on the firewall, why
are you querying the troublesome resolver directly? Do you get the same
result when querying the local unbound?
Same results from Unbound.
On Fri, Dec 06, 2013 at 01:50:33PM -0500, Chris Smith wrote:
Same results from Unbound. That's why I started digging.
Sorry if I'm missing something, but what lead you to suspect the
216.146.35.35 machine in the first place?
Given the +trace output you supplied that address is not part of
On Fri, Dec 6, 2013 at 2:35 PM, Patrik Lundin
patrik.lundin@gmail.com wrote:
Sorry if I'm missing something, but what lead you to suspect the
216.146.35.35 machine in the first place?
Some of my clients use that service and for them Unbound doesn't act
as a validator, just an iterator that
Thus said Chris Smith on Fri, 06 Dec 2013 11:31:23 -0500:
Basically, four of my networks are not getting an answer for a
specific mx query from dyn.com's DNS server. Yet every other DNS cache
I've queried works just fine (Google, Level3, Hurricane Electric,
Comcast, etc.) and
; Nigel J. Taylor
Objet : Re: Can't get relayd to work for DNS + problem with relayctl
reload
pierre,
i'm seeing the same result with relayctl i don't know where it's
coming from.
um
On Wed, Jan 14, 2009 at 8:16 AM, BARDOU Pierre bardo...@mipih.fr
wrote:
Shame on me, it didn't worked
Shame on me, it didn't worked because I allowed connexion to the real IP
(10.60.0.10x) and no to relayd IP (10.31.33.254).
Now it works, thanks for the help :)
But I still have the issue I reported a few monthes ago : when I use a relay,
relayctl reload fails saying command failed.
The relayd
Objet : Re: Can't get relayd to work for DNS + problem with relayctl reload
pierre,
i'm seeing the same result with relayctl i don't know where it's coming from.
um
On Wed, Jan 14, 2009 at 8:16 AM, BARDOU Pierre bardo...@mipih.fr wrote:
Shame on me, it didn't worked because I allowed
pierre,
i'm seeing the same result with relayctl i don't know where it's coming
from.
um
On Wed, Jan 14, 2009 at 8:16 AM, BARDOU Pierre bardo...@mipih.fr wrote:
Shame on me, it didn't worked because I allowed connexion to the real IP
(10.60.0.10x) and no to relayd IP (10.31.33.254).
Now it
31 matches
Mail list logo