Stuart Henderson wrote:
> On 2024-02-15, Rudolf Sykora wrote:
> > Josh Grosse wrote:
> >> On Thu, Feb 15, 2024 at 02:15:07PM +0100, rsyk...@disroot.org wrote:
> >> > my computer is connected to a LAN, from which it obtains its
> >> > IP and also local-DNS-server IP via DHCP. The latter is then
>
On 2024-02-15, Rudolf Sykora wrote:
> Josh Grosse wrote:
>> On Thu, Feb 15, 2024 at 02:15:07PM +0100, rsyk...@disroot.org wrote:
>> > my computer is connected to a LAN, from which it obtains its
>> > IP and also local-DNS-server IP via DHCP. The latter is then
>> > inserted into /etc/resolv.conf
Josh Grosse wrote:
> On Thu, Feb 15, 2024 at 02:15:07PM +0100, rsyk...@disroot.org wrote:
> > my computer is connected to a LAN, from which it obtains its
> > IP and also local-DNS-server IP via DHCP. The latter is then
> > inserted into /etc/resolv.conf by, I believe, resolvd. The
> > computer is
On Thu, Feb 15, 2024 at 02:15:07PM +0100, rsyk...@disroot.org wrote:
> my computer is connected to a LAN, from which it obtains its
> IP and also local-DNS-server IP via DHCP. The latter is then
> inserted into /etc/resolv.conf by, I believe, resolvd. The
> computer is furthermore connected via wir
Stuart Henderson wrote:
> There is a complication in Kaya's case because if my handle on the
> config is correct, there are likely to be nameservers learned from
> both DHCP (in one rdomain) and PPPOE (in another), but they won't
> work on the opposite connection.
>
> In this situation I would d
Kaya Saman wrote:
> Like I mentioned previously, it may have had something to do with me
> running: sh /etc/netstart pppoe0 a few times after the system had been
> booted. I was at the time trying to make use of 2 isp's and route
> accordingly per subnet or even ip address. It might have even bee
On 2023/04/12 13:20, Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2023-04-11, Theo de Raadt wrote:
> > > Kaya Saman wrote:
> > >
> > >> This somehow is overriding my resolv.conf file; another words the
> > >> information is *not* being used from resolv.conf and is instead being
> > >
On 4/12/23 20:20, Theo de Raadt wrote:
Stuart Henderson wrote:
On 2023-04-11, Theo de Raadt wrote:
Kaya Saman wrote:
This somehow is overriding my resolv.conf file; another words the
information is *not* being used from resolv.conf and is instead being
used from the ipcp negotiation as
Stuart Henderson wrote:
> On 2023-04-11, Theo de Raadt wrote:
> > Kaya Saman wrote:
> >
> >> This somehow is overriding my resolv.conf file; another words the
> >> information is *not* being used from resolv.conf and is instead being
> >> used from the ipcp negotiation as part of the pppoe kern
On 2023-04-11, Theo de Raadt wrote:
> Kaya Saman wrote:
>
>> This somehow is overriding my resolv.conf file; another words the
>> information is *not* being used from resolv.conf and is instead being
>> used from the ipcp negotiation as part of the pppoe kernel module.
>
> then the pppoe code sho
Kaya Saman wrote:
> This somehow is overriding my resolv.conf file; another words the
> information is *not* being used from resolv.conf and is instead being
> used from the ipcp negotiation as part of the pppoe kernel module.
then the pppoe code should submit a RTM_PROPOSAL route message ...
Thanks Stu, and everyone else who responded :-)
On 4/11/23 09:01, Stuart Henderson wrote:
On 2023-04-10, Kaya Saman wrote:
On 4/10/23 16:24, Daniele B. wrote:
Apr 10, 2023 12:52:22 Kaya Saman :
how do I override OpenBSD's
behavior to explicitly not use the dns servers obtained through ipcp
On 2023-04-10, Kaya Saman wrote:
>
> On 4/10/23 16:24, Daniele B. wrote:
>> Apr 10, 2023 12:52:22 Kaya Saman :
>>
> how do I override OpenBSD's
> behavior to explicitly not use the dns servers obtained through ipcp but
> instead use the ones form the resolv.conf file?
>> My solution bo
On 4/10/23 16:24, Daniele B. wrote:
Apr 10, 2023 12:52:22 Kaya Saman :
how do I override OpenBSD's
behavior to explicitly not use the dns servers obtained through ipcp but
instead use the ones form the resolv.conf file?
My solution both for security reasons (I'm using unbound)
for for practi
Apr 10, 2023 12:52:22 Kaya Saman :
>>> how do I override OpenBSD's
>>> behavior to explicitly not use the dns servers obtained through ipcp but
>>> instead use the ones form the resolv.conf file?
My solution both for security reasons (I'm using unbound)
for for practical reasons (as per your conc
On 4/10/23 11:40, Jonathan Gray wrote:
On Mon, Apr 10, 2023 at 11:26:22AM +0100, Kaya Saman wrote:
Hi,
I'll ask the second question first as it might be easier to implement...
Currently I have found that the dns servers specified in the resolv.conf
file are not being used. Instead my machi
On Mon, Apr 10, 2023 at 11:26:22AM +0100, Kaya Saman wrote:
> Hi,
>
>
> I'll ask the second question first as it might be easier to implement...
>
>
> Currently I have found that the dns servers specified in the resolv.conf
> file are not being used. Instead my machine is prioritizing the ISP o
On Tue, 14 Dec 2021 15:38:08 +0100
Stefan Sperling wrote:
> On Tue, Dec 14, 2021 at 12:49:14PM +, Dave Turner wrote:
> > I have searched the web and tried various things but so far nothing
> > fixes it.
>
> This should help:
> https://marc.info/?l=openbsd-bugs&m=163459084214897&w=2
Stefan
On Tue, Dec 14, 2021 at 12:49:14PM +, Dave Turner wrote:
> I have searched the web and tried various things but so far nothing
> fixes it.
This should help: https://marc.info/?l=openbsd-bugs&m=163459084214897&w=2
and make sure there is a route to Route to your Internal DNS servers
over the VPNs
Or
a policy that covers the DNS servers ip range if it is an Ipsec
policy based vpn
Hope this helps
On Tue, 20 Jul 2021 at 13:15, Timo Myyrä wrote:
>
> Stuart Henderson [2021-07-20, 11:24 +]:
>
> > On 2021-
Stuart Henderson [2021-07-20, 11:24 +]:
> On 2021-07-20, Timo Myyrä wrote:
>
>> Hi,
>>
>> Just started testing the new dhcleased,resolvd stuff and noticed that
>> DNS resolution won't work correctly once I open my VPN connection. Name
>> resolution works for external domains but not for the
On 2021-07-20, Timo Myyrä wrote:
> Hi,
>
> Just started testing the new dhcleased,resolvd stuff and noticed that
> DNS resolution won't work correctly once I open my VPN connection. Name
> resolution works for external domains but not for the internal domains
> resolved by the interal DNS servers.
Hi,
James(ja...@jmp-e.com) on 2020.05.28 11:12:29 +0100:
> Thanks. Your solution works but is not ideal for my situation. The
> reason it's not ideal is that one of the rdomains gets its nameserver
> from DHCP and I don't think unbound can read this information.
>
> For example, In the case of a
Thanks. Your solution works but is not ideal for my situation. The
reason it's not ideal is that one of the rdomains gets its nameserver
from DHCP and I don't think unbound can read this information.
For example, In the case of a captive portal or floating between APs I
would like DNS to work on
Unbound can use root hints
And you can over ride nameservers learned from dhclient
Check man dhclient for more info
And Set your resolv.conf nameservers to 127.0.0.1
Peace out
On Thursday, 28 May 2020, James wrote:
> Thanks. Your solution works but is not ideal for my situation. The
>
oh yeah you will have to adjust the flags for each daemon (to accept a
different
config file for each dns server in each Rdomain...
hope this helps...
On Wed, 27 May 2020 at 23:35, Tom Smyth
wrote:
> howdy,
>
> you can use symbolic links for /etc/rc.d/nsd to /etc/rc.d/nsd1
> and to/etc/r
howdy,
you can use symbolic links for /etc/rc.d/nsd to /etc/rc.d/nsd1
and to/etc/rc.d/nsd2 to /etc/rc.d/nsdn where 1,2 n are your r
domains for your
dns servers (authoritive) or you can use unbound instead of nsd
if it is just a forwarding dns server
then use for a dns server for rdo
On Thu, Jan 23, 2020, Stuart Henderson wrote:
> On 2020-01-22, Claus Assmann wrote:
> > The functional tests for sendmail use ldns-testns as DNS server
> > which provides specific test data and error behaviours.
> > It runs on a port > 1024 to avoid requiring root access.
> For the libbind port,
On 2020-01-22, Claus Assmann wrote:
> The functional tests for sendmail use ldns-testns as DNS server
> which provides specific test data and error behaviours.
> It runs on a port > 1024 to avoid requiring root access.
> There's code in sendmail to set the IP and port for a NS:
> _res.nsadd
Claus Assmann wrote:
> The functional tests for sendmail use ldns-testns as DNS server
> which provides specific test data and error behaviours.
> It runs on a port > 1024 to avoid requiring root access.
you can use a combination of pf.conf rdr-to and 127.0.0.2 etc.
i.e., bind to port 5353, have
Aren’t new version enabling (some.host) to not race ?
On Thu, Jul 4, 2019 at 7:26 AM Andy Lemin wrote:
> Hey guys.
>
> Thanks for the ideas. Sadly I cannot use static IPs as we don’t control
> the domains.
>
> I think I’ll use Otto’s suggestion as I am already doing that to provide a
> black hol
Hey guys.
Thanks for the ideas. Sadly I cannot use static IPs as we don’t control the
domains.
I think I’ll use Otto’s suggestion as I am already doing that to provide a
black hole table for the spamhaus drop list. So I’ll just enhance that script
to manage some more tables 😀
After all, the c
On Thu, Jul 04, 2019 at 09:14:19AM +0100, Andy Lemin wrote:
> Hi guys,
>
> Is anyone else aware of the Unbound and PF race condition that exists when
> FQDNs are used in pf.conf with a local Unbound server?
Yes, it's an obvious one isn't it?
>
> The issue occurs when pf starts before unbound,
Hi NN,
On Wed, 29 Aug 2018 11:57:15 +0200 NN wrote:
>
> here is my pf.conf on VM#1:
>
> int_if="{ vether0 re0 }"
> set block-policy drop
> set log interface egress
> set skip on lo0
> match in all scrub (no-df random-id max-mss 1440)
> match out on egress inet from
On 2018-08-29, NN wrote:
> Hi,
>
> All is working for me with new ACL Rule:
>
> access-control: 0.0.0.0/0 allow
>
> Many Thanks Solène Rapenne !
>
> ISSUE is closed.
>
> P.S.
>
> Why opening unbound to the internet is a bad idea ???
Because your resolver *will* be found and quite likely peop
Hi,
All is working for me with new ACL Rule:
access-control: 0.0.0.0/0 allow
Many Thanks Solène Rapenne !
ISSUE is closed.
P.S.
Why opening unbound to the internet is a bad idea ???
Thx.
On 08/29/18 12:51, Solène Rapenne wrote:
Le 2018-08-29 12:41, NN a écrit :
Hi,
many thanks for y
Le 2018-08-29 11:57, NN a écrit :
*Hi all,*
*Its my first topic here =)
*
*Please help me investigate DNS+PF issue. **
*
*I have 2 VM on OpenBSD 6.3:*
* VM#1 - Router with PF, IP:192.168.50.1*
* VM#2 - DNS (as unbound), IP:192.168.50.2**
*
*here is my pf.conf on VM#1:*
int_if="{
Le 2018-08-29 12:41, NN a écrit :
Hi,
many thanks for your quick answer,
I try to use your PF rule, and got the same answer from my DNS:
...
>> WARNING: recursion requested but not available
...
I need the DNS request RULE's for my PF
Any ideas?
BR
deface
On 08/29/18 12:34, Arn
Hi,
many thanks for your quick answer,
I try to use your PF rule, and got the same answer from my DNS:
...
>> WARNING: recursion requested but not available
...
I need the DNS request RULE's for my PF
Any ideas?
BR
deface
On 08/29/18 12:34, Arnaud BRAND wrote:
Le 2018-08-29 11:
On 19:27 Fri 02 Mar, Stuart Henderson wrote:
> On 2018-03-01, Consus wrote:
> > Let's Encrypt is going to support wildcard certificates soon enough, but
> > only through DNS-01 challenge, but acme-client(1) does not support it.
> > Have you guys considered implemeting DNS challenges? Maybe someon
On 2018-03-01, Consus wrote:
> Let's Encrypt is going to support wildcard certificates soon enough, but
> only through DNS-01 challenge, but acme-client(1) does not support it.
> Have you guys considered implemeting DNS challenges? Maybe someone is
> already working on the implementation? If not
On 15:46 Fri 02 Mar, Consus wrote:
> On 11:45 Fri 02 Mar, Etienne wrote:
> > Well, really, what you're asking for is having acme-client offload the
> > complicated stuff (set the TXT records, then check for verification) to a
> > script, which to me looks pretty much the same as writing a script to
On 11:45 Fri 02 Mar, Etienne wrote:
> Well, really, what you're asking for is having acme-client offload the
> complicated stuff (set the TXT records, then check for verification) to a
> script, which to me looks pretty much the same as writing a script to do
> everything.
I'm not. Writing TXT ent
On 01/03/18 14:39, Consus wrote:
It is more complicated than creating a file in a folder.
With a little luck it's not. Both NSD and BIND allow you to include
files in zone configuration like this:
[...]
The only problem here is #3, but it's possible to create e.g. another
pledged process tha
On 15:20 Thu 01 Mar, Solène Rapenne wrote:
> It is not easy to implement because this requires access to your
> DNS server (like nsd or bind) or your registrar admin API which would
> require adding plugins for each API.
Well... that's why it's called DNS challenge, right?
> It is more complicate
Le 2018-03-01 10:45, Consus a écrit :
Hi,
Let's Encrypt is going to support wildcard certificates soon enough,
but
only through DNS-01 challenge, but acme-client(1) does not support it.
Have you guys considered implemeting DNS challenges? Maybe someone is
already working on the implementation
On 2017-06-19, Rui Ribeiro wrote:
> Depending on how "evil" the ISP is, or how you want to obfuscate your
> metadata, you might want to have a look at dnscrypt
> https://blog.ipredator.se/openbsd-dnscrypt-howto.html
Yes, that's an option, though it does just move your trust from the ISP
to the dn
Hi,
Depending on how "evil" the ISP is, or how you want to obfuscate your
metadata, you might want to have a look at dnscrypt
https://blog.ipredator.se/openbsd-dnscrypt-howto.html
On 18 June 2017 at 10:59, Stuart Henderson wrote:
> On 2017-06-17, Paul Suh wrote:
> > Folks,=20
> >
> > My unders
On 18/06/2017 10:59, Stuart Henderson wrote:
> On 2017-06-17, Paul Suh wrote:
>> Folks,=20
>>
>> My understanding of the way that this is done is by returning a CNAME =
>> when the ISP's DNS recursive DNS server would otherwise return a =
>> NXDOMAIN result, followed by a HTTP 302 when the browse
On 2017-06-17, Paul Suh wrote:
> Folks,=20
>
> My understanding of the way that this is done is by returning a CNAME =
> when the ISP's DNS recursive DNS server would otherwise return a =
> NXDOMAIN result, followed by a HTTP 302 when the browser attempts to =
> reach the host via the bogus CNAME
On 2016-06-30, Kapetanakis Giannis wrote:
> On 30/06/16 16:01, Stuart Henderson wrote:
>> On 2016-06-30, Kapetanakis Giannis wrote:
>>> Hi,
>>>
>>> a) I'm asking if there is any program in base for dns lookups that support
>>> port for name server.
>>
>> Not in base, you will need packages.
>>
On 30/06/16 21:11, Alexander Hall wrote:
I guess you could play some games with pf(4) for a single occasion:
# ifconfig lo0 127.0.0.2 alias
# in pf.conf:
set skip on none
pass on lo
pass on lo0 from any to 127.0.0.2 port 53 rdr-to 127.0.0.2 port 5678
(and maybe sth more I might be missing)
/A
On Thu, Jun 30, 2016 at 01:01:58PM +, Stuart Henderson wrote:
> On 2016-06-30, Kapetanakis Giannis wrote:
> > Hi,
> >
> > a) I'm asking if there is any program in base for dns lookups that support
> > port for name server.
>
> Not in base, you will need packages.
I guess you could play some
On 30/06/16 16:16, Kapetanakis Giannis wrote:
> understood and thanks for the reply.
>
> Would you think to add libldns/drill in base or is it out of question?
>
> G
forget that I asked. Even linbldns seems abandoned an drill does not have what
I need (apart from -p)
dig from newer bind packa
On 30/06/16 16:01, Stuart Henderson wrote:
> On 2016-06-30, Kapetanakis Giannis wrote:
>> Hi,
>>
>> a) I'm asking if there is any program in base for dns lookups that support
>> port for name server.
>
> Not in base, you will need packages.
>
>> b) would a patch for this in src/usr.sbin/bind/ b
On 2016-06-30, Kapetanakis Giannis wrote:
> Hi,
>
> a) I'm asking if there is any program in base for dns lookups that support
> port for name server.
Not in base, you will need packages.
> b) would a patch for this in src/usr.sbin/bind/ be accepted or is
> there a reason for this to be out (ex
On Tue, Jun 14, 2016 at 3:49 PM, Chris Bennett
wrote:
> On Tue, Jun 14, 2016 at 09:05:57PM +0100, Stuart Henderson wrote:
>>
>> If you can't find some other way to get things working then at least
>> you should be able to browse by "ssh -D 1080 somehost" and setting the
>> browser to use 127.0.0.1
On 2016 Jun 14 (Tue) at 11:38:03 -0700 (-0700), Christopher Ahrens wrote:
:li...@wrant.com wrote:
:>Tue, 14 Jun 2016 11:46:39 -0500 Chris Bennett
:>
:>>$ dig bsd.org @8.8.4.4 +trace
:>>dig: couldn't get address for 'm.root-servers.net': not found
:>>
:>>pass ~ $ dig bsd.org @8.8.8.8 +trace
:>>dig
> > > > I don't know if this will be usable for your case, here at home the aDSL
> > > > modem tries to be the resolver. The trouble is with the ISP: their DNS
> > > > servers are quite frequently unreliable and unstable. They even affect
> > > > the PPP connection sate, as the modem firmware use
On Tue, Jun 14, 2016 at 09:05:57PM +0100, Stuart Henderson wrote:
>
> If you can't find some other way to get things working then at least
> you should be able to browse by "ssh -D 1080 somehost" and setting the
> browser to use 127.0.0.1:1080 as SOCKS proxy, and tell it to have the
> far end reso
Tue, 14 Jun 2016 14:50:57 -0500 Chris Bennett
> > Could you trip the power to the wifi translating network segment?
>
> Possibly, but since mostly even the mains coming into large buildings
> aren't even fully enclosed with metal, might get severe burns and eye
> damage from the arc-flash.
> But
On 2016/06/14 13:48, Chris Bennett wrote:
> On Tue, Jun 14, 2016 at 05:28:48PM +, Stuart Henderson wrote:
> > On 2016-06-14, Chris Bennett wrote:
> > > They both work for me also, with dig @8.8.8.8, etc.
> > > Whois fails, lynx, elinks, firefox cannot connect outside
> > >
> > > Could this pro
Tue, 14 Jun 2016 13:48:56 -0500 Chris Bennett
> > > They both work for me also, with dig @8.8.8.8, etc.
> > > Whois fails, lynx, elinks, firefox cannot connect outside
> > >
> > > Could this problem be because of my being behind the wifi NAT?
Could you trip the power to the wifi translating net
Tue, 14 Jun 2016 11:38:03 -0700 Christopher Ahrens
> li...@wrant.com wrote:
> > Tue, 14 Jun 2016 11:46:39 -0500 Chris Bennett
> >
> >> $ dig bsd.org @8.8.4.4 +trace
> >> dig: couldn't get address for 'm.root-servers.net': not found
> >>
> >> pass ~ $ dig bsd.org @8.8.8.8 +trace
> >> dig: coul
On Tue, Jun 14, 2016 at 05:28:48PM +, Stuart Henderson wrote:
> On 2016-06-14, Chris Bennett wrote:
> > They both work for me also, with dig @8.8.8.8, etc.
> > Whois fails, lynx, elinks, firefox cannot connect outside
> >
> > Could this problem be because of my being behind the wifi NAT?
>
>
li...@wrant.com wrote:
Tue, 14 Jun 2016 11:46:39 -0500 Chris Bennett
$ dig bsd.org @8.8.4.4 +trace
dig: couldn't get address for 'm.root-servers.net': not found
pass ~ $ dig bsd.org @8.8.8.8 +trace
dig: couldn't get address for 'i.root-servers.net': not found
You know I'm thinking you may
On 2016-06-14, Chris Bennett wrote:
> They both work for me also, with dig @8.8.8.8, etc.
> Whois fails, lynx, elinks, firefox cannot connect outside
>
> Could this problem be because of my being behind the wifi NAT?
Compare the full output from resolving there with dig with the same
thing ssh'd
Chris Bennett wrote:
$ dig bsd.org @8.8.4.4 +trace
; <<>> DiG 9.4.2-P2 <<>> bsd.org @8.8.4.4 +trace
;; global options: printcmd
. 7197IN NS a.root-servers.net.
. 7197IN NS b.root-servers.net.
. 7197
Chris Bennett said:
> Neither 8.8.8.8 or 8.8.4.4 works.
What does that mean, precisely? Can you ping them?
--
Dmitrij D. Czarkoff
Tue, 14 Jun 2016 11:46:39 -0500 Chris Bennett
> $ dig bsd.org @8.8.4.4 +trace
> dig: couldn't get address for 'm.root-servers.net': not found
>
> pass ~ $ dig bsd.org @8.8.8.8 +trace
> dig: couldn't get address for 'i.root-servers.net': not found
You know I'm thinking you may be behind capt
On 2016-06-14, Chris Bennett wrote:
> This happens here in Mexico and also in Guatemala.
> But it has been about five days now. Enough!
>
> dig works fine, locally and using the server my USA website uses.
> I tried adding that to /etc/resolv.conf and .tail but no help.
> whois fails.
> Digging ev
$ dig bsd.org @8.8.4.4 +trace
; <<>> DiG 9.4.2-P2 <<>> bsd.org @8.8.4.4 +trace
;; global options: printcmd
. 7197IN NS a.root-servers.net.
. 7197IN NS b.root-servers.net.
. 7197IN NS c.
Hi Chris,
Does your network works fine, can you reach icmp at 8.8.8.8 for example?
Try the flag +trace with dig and see where it ends.
like: dig whatever.com @8.8.8.8 +trace
Best Regards,
2016-06-14 11:12 GMT-03:00 Chris Bennett <
chrisbenn...@bennettconstruction.us>:
> This happens here in Mexi
dig mx bsd.org @8.8.4.4
dig mx bsd.org @8.8.8.8
both work for me
On Tue, Jun 14, 2016 at 9:27 PM, Chris Bennett <
chrisbenn...@bennettconstruction.us> wrote:
> They both work for me also, with dig @8.8.8.8, etc.
> Whois fails, lynx, elinks, firefox cannot connect outside
>
> Could this proble
I don't know if this will be usable for your case, here at home the aDSL
modem tries to be the resolver. The trouble is with the ISP: their DNS
servers are quite frequently unreliable and unstable. They even affect
the PPP connection sate, as the modem firmware uses that to trigger self
induced r
They both work for me also, with dig @8.8.8.8, etc.
Whois fails, lynx, elinks, firefox cannot connect outside
Could this problem be because of my being behind the wifi NAT?
Chris Bennett
On Tue, Jun 14, 2016 at 06:50:53PM +0300, li...@wrant.com wrote:
> I don't know if this will be usable for your case, here at home the aDSL
> modem tries to be the resolver. The trouble is with the ISP: their DNS
> servers are quite frequently unreliable and unstable. They even affect
> the PPP c
Tue, 14 Jun 2016 11:08:17 -0500 Chris Bennett
> On Tue, Jun 14, 2016 at 06:50:53PM +0300, li...@wrant.com wrote:
> > I don't know if this will be usable for your case, here at home the aDSL
> > modem tries to be the resolver. The trouble is with the ISP: their DNS
> > servers are quite frequently
both 8.8.8.8 and 8.8..4.4 work for me.
On Tue, Jun 14, 2016 at 8:26 PM, Chris Bennett <
chrisbenn...@bennettconstruction.us> wrote:
> Neither 8.8.8.8 or 8.8.4.4 works.
> After netstart, no. After reboot, no.
>
>
--
cat /etc/motd
Thank you
Indunil Jayasooriya
http://www.theravadanet.net/
htt
Neither 8.8.8.8 or 8.8.4.4 works.
After netstart, no. After reboot, no.
Chris Bennett said:
> This happens here in Mexico and also in Guatemala.
> But it has been about five days now. Enough!
>
> dig works fine, locally and using the server my USA website uses.
> I tried adding that to /etc/resolv.conf and .tail but no help.
> whois fails.
> Digging every site I want
On Thu, Dec 11, 2014 at 04:13:13PM +, Zé Loff wrote:
> TL,DR:
> Queries to DNS server over IPSec made using host or dig work OK,
> requests made by e.g. ping exit the enc0 interface but don't show up on
> enc0 on the other end.
>
>
> Hi all
>
> I'm puzzled by some weird stuff happening with
First of all, I have no real clue. It sound weird. But maybe I can help
you at least with that one:
Am Donnerstag, den 11.12.2014, 16:13 + schrieb Zé Loff:
> However, if I try to do something like "ping -c 1 www_lan.foo.bar" (or
> e.g. ssh) I can see the packets with the DNS request pass throu
Hey man,
I'm not sure about what is happening, but pflog is your best friend ever !
http://www.openbsd.org/faq/pf/logging.html
Try find out if a specific rule is blocking traffic in one of endpoints (
both ? )
Cheers,
2014-12-11 14:13 GMT-02:00 Zé Loff :
> TL,DR:
> Queries to DNS server over
Thanks to all for your replies but... I'm sorry for the misleading
Subject of this thread, I meant "delegation NS records" (not "glue
records").
Below is the answer from bind-us...@lists.isc.org.
--
Alexei
Original Message
Subject: Re: DNS: how
Thus said Alexei Malinin on Fri, 05 Dec 2014 15:49:59 +0300:
> - the question is - how and with what tools (dig, host, nslookup, or
> maybe C or Perl libs) can I verify the NS glue records in the parent
> zone of my ISP (zone transfers are denied)?
The entries in the ADDITIONAL SECTION below
On Fri, Dec 05, 2014 at 03:49:59PM +0300, Alexei Malinin wrote:
>
> I would like to resolve this problem:
> - I have a child DNS zone served by my ISP slave name server;
> - the parent zone is served by my ISP master name server;
It appears to me what you refer to as "master name server" above ar
On 2014-12-05 Fri 15:49 PM |, Alexei Malinin wrote:
>
> My child zone is 0-15.66.233.212.in-addr.arpa. I tried "dig -4
> +multiline +showsearch +trace 0-15.66.233.212.in-addr.arpa ns" but it
> was not possible to make any conclusions about NS glue records from the
> dig output.
>
Try this Alexei
On Dec 20 00:36:02, mikael.tr...@gmail.com wrote:
> Seems that by default OpenBSD's DNS resolver rotates what DNS server from
> /etc/resolv.conf it uses, and when the DNS server used for a resolve does
> not work, the DNS resolve fails;
>
> Perhaps not exactly like this, but clearly in this direct
* Mikael [2013-12-20 09:58:39 +0200]:
> Hi Matthew,
>
> Aha so the files of reference are asr.c (
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/asr.c?rev=1.31;content-type=text%2Fplain
> )
> and res_send_async.c (
> http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/res_send_async
Hi Matthew,
Aha so the files of reference are asr.c (
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/asr.c?rev=1.31;content-type=text%2Fplain
)
and res_send_async.c (
http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/asr/res_send_async.c?rev=1.19;content-type=text%2Fplain
)
Do I unders
On Thu, Dec 19, 2013 at 2:36 PM, Mikael wrote:
> a) OpenBSD's resolver configured to retry 999 times before failing, and
> [...]
> If so, is there any way to do a)?
In src/lib/libc/asr/asr.c, change "ac->ac_nsretries = 4;" to
"ac->ac_nsretries = 999;", recompile, and reinstall.
However, I wouldn
Maybe try configuring bind (read the manuals and online docs) and setting
resolv.conf to 127.0.0.1 would be a good start.
OpenBSD's resolv logic won't be 'fixed' unless you want to change the code..
Sent from my iPhone
> On 19 Dec 2013, at 22:36, Mikael wrote:
>
> Seems that by default OpenBS
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 sh
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
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
On Fri, Dec 6, 2013 at 2:35 PM, Patrik Lundin
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 forwards non-local queries
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
On Fri, Dec 6, 2013 at 1:38 PM, Patrik Lundin
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. That's why I started "diggin
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
1 - 100 of 217 matches
Mail list logo
