>
> In this particular case, isn't the resolver attempting to do a reverse
> lookup of the IP address that's listed ?
>
>
You are right, I missed that this is a reverse-mapping zone. In that case,
run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and you'll see
the problem.
DS = Delegation Signer, it is the record type that a signed child upload to
the parent zone. It's difficult to say for sure without more information
such as which domain name you are trying to resolve, but looks like it is
probably due to a mis-matching DS record between the child and the parent
Hello,
I am trying to use delv (version 19.8.2 on Ubuntu 0.22.04) to troubleshoot
using a custom trust anchor. However, I am getting very strange results
from delv. The short of it is, I must point delv at another validating
resolver (such as @8.8.8.8) for the custom trust anchors (-a) to work.
You are correct. Normal stub resolvers on desktop clients or mobile devices
only see the AD flag (or SERVFAIL when validation fails). They will only
get all the additional DNSSEC record types if they used the +dnssec option
in dig (which sets the DO bit in the outbound query).
On Tue, Apr 11,
Hi all,
I know this is a strange request. I am trying to encourage more people to
deploy DNSSEC (either authoritative or recursive/validating). Are there any
compliance or regulatory requirements that suggest/recommend the use of
DNSSEC?
The only one I know of is the very dated US OMB memo from
.info named[4022]: no valid RRSIG resolving
> 'c1.example.home/DS/IN': 192.168.14.20#53
> Jul 20 15:38:06 ns1 daemon.info named[4022]: insecurity proof failed
> resolving 'c1.example.home/A/IN': 192.168.14.20#53
>
>
> and there is no log entries on the authoritative server
>
&
In order for us to help you better, you need to provide more information.
What makes you think The recursive resolver is slow? Do you have syslog? Is
the BIND instance slow, or is it the operating system (low RAM? Slow disk?)
or is this a network-related issue?
On Thu, Mar 12, 2020 at 11:00 AM
Tony,
Thank you for that detailed explanation.
On Wed, Jul 3, 2019 at 2:15 AM Tony Finch wrote:
> Josh Kuo wrote:
> >
> > There are 6 DS records total, but only 1 RRSIG. This leads me to believe
> > that the single RRSIG is generated by somehow concatenating all DS
&
..@isc.org
>
> > On 2 Jul 2019, at 19:34, Josh Kuo wrote:
> >
> > This may not be the right place to ask, if this is a better question
> asked in a different list, please let me know.
> >
> > I am curious as to how BIND generates and processes DS RRSIG, and this
&
This may not be the right place to ask, if this is a better question asked
in a different list, please let me know.
I am curious as to how BIND generates and processes DS RRSIG, and this may
not be unique to BIND, since I've seen this behavior across multiple
vendors. From the following:
$ dig
Agree with Tony on TCP not going to be tried. Have you looked at using
anycast? It is not true load balancing but it allows you to stand up
multiple DNS servers that “shares” a single IP address.
On Wed, Feb 20, 2019 at 12:25 AM Tony Finch wrote:
> Roberto Carna wrote:
>
> > Dear, I have to
You might want to check out the free service offered by Quad Nine
(9.9.9.9), they use RPZ in the backend to filter out known malicious domain
names. I do not know if they can filter out malware-related names.
On Sat, Jan 20, 2018 at 7:02 AM Syaifudin wrote:
> Hi Daniel
>
>
Add www.mydomain.co.nz to your internal zone, that is one common way to deal
with it. With BIND you can keep the common records in a separate file and use
include statement to avoid double entry.
On Aug 9, 2015, at 12:50 AM, Dave Koelmeyer
dave.koelme...@davekoelmeyer.co.nz wrote:
On
If all you are after is one of the final IP addresses (not the entire
set), then using a dumb client might be easier. For instance, 'ping'.
$ ping -q -c1 www.google.com
PING www.google.com (203.66.155.113): 56 data bytes
If you want to get more than one IP address, then you'll need an
In other words, if your goal is to identify latency in your resolver, it's
probably best to run tcpdump on the resolver itself, and analyze the
traffic capture to see if there are any latency. The +trace shows you what
should happen.
On Wed, Nov 7, 2012 at 3:05 PM, david r...@nachtmaus.us wrote:
If I am not mistaken, when you do +trace, the trace actually comes
from your machine running 'dig', and not the DNS resolver itself.
(Others on list please correct me)
Can you perform the same 'dig' query from the DNS server, without
specifying which resolver to use? This smells like the DNS
I tried these myself, and I am still scratching my head on the results.
First, I tried to look for just ftp.cisco.com's A record, and I got back the
answer 198.133.219.241.
$ dig @4.2.2.2 ftp.cisco.com. a
; DiG 9.4.3-P3 @4.2.2.2 ftp.cisco.com. a
; (1 server found)
;; global options: printcmd
was hoping there is some way to mimic traceroute with
dig +trace, I didn't think so, and Mark confirmed it.
On Sunday, April 25, 2010, Warren Kumari war...@kumari.net wrote:
On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
You need administrative access to see the overides to the normal resolution
You need administrative access to see the overides to the normal resolution
process.
Just so I understand this completely, by administrative access you mean I
need to be able to log in to each of the resolvers (not administrative
access on my local workstation to do a 'sudo dig example.net a
Check out views or split DNS.
On Sunday, November 15, 2009, Peter Macko peter_ma...@msn.com wrote:
Setup:I have a domain example.com that is hosted on DNS under control of my
internet provider.Web server www.example.com is hosted by another company.I
have setup a local DNS for computers
Small home linksys router running open WRT can do the job, with 16MB
of RAM and some low powered MIPS CPU.
On Saturday, September 19, 2009, Frank Bulk frnk...@iname.com wrote:
Perhaps the inverse would be more interesting: what's the lowest-spec
hardware that could host an OS that would run the
1) If a reply is over 512 bytes, which can't in theory be done via UDP,
should the queried server reply telling my resolver to ask again using
TCP? Assuming, as one normally should, that there are firewalls, the
queried server can't simply reply TCP, as it would get blocked.
I am not sure
I believe the behavior of the following configuration is to send back
the IP address of the forwarders to the clients, and rely on clients
to do the recursive query against the forwarders.
On Tue, Jan 20, 2009 at 9:25 AM, etirado@orange-ftgroup.com wrote:
Hello,
Is this possible to
Oops, I missed that part. Sorry, yes, as Ben pointed out, my proposed
solution will take over *ALL* records in somedomain.com, anything you
don't list in your somedomain.com will NOT be resolved.
___
bind-users mailing list
bind-users@lists.isc.org
dig @nameserver zone axfr
For example:
dig @10.10.10.10 my.domain.com axfr
you need to allow zone transfer.
On Wed, Dec 17, 2008 at 1:50 AM, Fred Zinsli fred.zin...@shooter.co.nz wrote:
Hello all
Well I have a basic setup going and it seems to function.
What I am wanting to know is, is
25 matches
Mail list logo