> The facts are:
>
> * 191.131.in-addr.arpa is served from awsdns
Correct. And it's delegated to from the 131.in-addr.arpa zone,
maintained by ARIN.
> * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com
> and ns102.click-network.com above the zone cut.
Correct.
> * Be
Trace from my location dies even earlier:
;; Received 915 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 17 ms
;; connection timed out; no servers could be reached
Again just a data point.
> On 24 Apr 2024, at 22.03, tale via bind-users
> wrote:
>
> Hmm, I wonder if qname-minimisat
As further data points with BIND as a caching / recursive sometimes it
"works" and provides inconsistent AUTHORITY, although anecdata suggests
this is more prevalent with older versions of BIND. In one case BIND
9.12 reports the AUTHORITY as the parent zone in fact, with the parent's
nameservers.
They've got a number of problems. click-network.com is one of them.
https://dnsviz.net/d/click-network.com/dnssec/
There is some backstory. The City of Tacoma used to run broadband,
and that was Click! Network. The origin story is that this had something
to do with SCADA or power distribut
Hmm, I wonder if qname-minimisation is at issue here. My trace dies with:
85.191.131.in-addr.arpa. 1800 IN NS fs838.click-network.com.
85.191.131.in-addr.arpa. 1800 IN NS ns102.click-network.com.
couldn't get address for 'fs838.click-network.com': not found
couldn't get a
While BIND 9.18.21 with "qname-minimization strict;" SERVFAILs on the
following query, dig with +trace resolves it. Just a data point, and if
they fix their s**t and stop impersonating a signed zone then presumably
the example will resolve itself (pun intended).
dig -x 131.191.85.31
dig -x 131.19
Gregory Sloop wrote:
> Would you mind showing me how you got there?
I like https://dnsviz.net/ and https://zonemaster.net/ - dnsviz is better
at showing DNSSEC issues, and zonemaster has a bigger collection of
general DNS checks, so it's worth using them both.
Tony.
--
f.anthony.n.finchhtt
dig +trace +all and it stood out.
> On 3 Mar 2021, at 13:20, Gregory Sloop wrote:
>
> Would you mind showing me how you got there?
> [The answer is fab, obviously. But give a man a fish...and all that. :) ]
>
> -Greg
>
>
>
> MA> The COM servers have stale
r.com. 172800 IN A 216.65.128.5
MA> webns.pacifier.com. 172800 IN A 216.65.128.1
MA> vs
MA> srvns.pacifier.com. 86400 IN A 64.255.237.241
MA> webns.pacifier.com. 86400 IN A 64.255.237.240
MA> The later set of servers are
.65.128.1
MA> vs
MA> srvns.pacifier.com. 86400 IN A 64.255.237.241
MA> webns.pacifier.com. 86400 IN A 64.255.237.240
MA> The later set of servers are what you query when you run dig +trace.
MA> If you prime the cache the plain lookup should work. Re
set of servers are what you query when you run dig +trace.
If you prime the cache the plain lookup should work. Report the out
of date glue to the zone administrator.
Mark
> On 3 Mar 2021, at 13:06, Gregory Sloop wrote:
>
> I've got a case, (and I see several other similar reports)
I've got a case, (and I see several other similar reports) where BIND is
failing to find an A record for a domain.
Yet a dig +trace does.
(I'm doing the dig on the BIND server. It's set to be a root resolving server,
not a forwarder.)
As I understand this, +trace will also invol
7;m not understanding about dig's intended behavior.
>
> "dig +trace" does not appear to be following referrals with a non-empty
> answer section, e.g. with CNAMEs pointing below the zone cut. I tried this
> with dig from several versions (9.11.x, 9.14.x, and 9.16.x) with the
Hi folks,
I thought I'd check here before filing a bug in the gitlab repo -- in case
there is something I'm not understanding about dig's intended behavior.
"dig +trace" does not appear to be following referrals with a non-empty
answer section, e.g. with CNAMEs point
> I am also interested in understanding the reasons behind this
> behaviour, especially after reading the following snippet from the
> official knowledge base [1]:
Thank you for pointing out the official documentation.
dig didn't even implement it according to its official documentation!
Hello list,
I am also interested in understanding the reasons behind this
behaviour, especially after reading the following snippet from the
official knowledge base [1]:
When following delegation iteratively as specified with the +trace
option, dig will begin by requesting the NS records fo
As we all know, dig +trace can perform iterative queries, starting from the
root name server, to the top-level name server, and then to the name server of
the second-level domain name.
8 7.158512318 192.168.3.34 → 1.1.1.1 DNS 82 Standard query 0x6ab6 NS
OPT
9 7.324926676 1.1.1.1
In message ,
Anand Buddhdev wrote:
>On 21/06/2019 22:01, Ronald F. Guilmette wrote:
>> I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
>> Until then I have a nice temprary workaround, which is to just append
>> @a.root-servers.net to my di
On 21/06/2019 22:01, Ronald F. Guilmette wrote:
Hi Ronald,
> I'll switch to using the 9.14.3 or 9.15.0 dig command as soon as possible.
> Until then I have a nice temprary workaround, which is to just append
> @a.root-servers.net to my dig +trace commands.
Just one note. 9.15.
In message ,
Anand Buddhdev wrote:
>On 21/06/2019 04:55, Ronald F. Guilmette wrote:
>
>> What is it about unbound/local-unbound that makes it not plug and play well
>> with dig +trace? What is it that Google's public name servers are doing
>> that a local runni
On 21/06/2019 04:55, Ronald F. Guilmette wrote:
> What is it about unbound/local-unbound that makes it not plug and play well
> with dig +trace? What is it that Google's public name servers are doing
> that a local running instance of unbound and/or local-unbound isn't doi
cking now, I think I see the problem. There is some sort of a problematic
interaction happening -only- between "dig +trace" and either unbound or
local-unbound.
On my old Ubuntu 16.04 system, /etc/resolv.conf contains only:
nameserver 8.8.8.8
nameserver 8.8.4.4
(Those are
Are you sure it's not your setup?
I have plenty of dig running on FreeBSD (with bind-utils 9.14) and also Debian
and they work just fine.
--
Nico
> On 21 Jun 2019, at 09:14, Ronald F. Guilmette wrote:
>
> In message <9ba154cc-2272-46ec-a793-47ff31dca...@arin.net>, you wrote:
>
>> Hi Ronald,
In message <9ba154cc-2272-46ec-a793-47ff31dca...@arin.net>, you wrote:
>Hi Ronald,
>You usually need to reinstall packages and ports after you do a major
>version upgrade to FreeBSD.
I guess that I did not make myself clear. Everything on this system is
freshly installed, from scratch.
I have t
s,
—Matt
> On Jun 20, 2019, at 5:33 PM, Ronald F. Guilmette
> wrote:
>
> I just recently "upgraded" my old FreeBSD system to the latest, 12.0
> release. Now, something that used to work doesn't seem to work anymore,
> specifically "dig +trace&quo
I just recently "upgraded" my old FreeBSD system to the latest, 12.0
release. Now, something that used to work doesn't seem to work anymore,
specifically "dig +trace" seems to no longer function at all.
Example:
===========
;re
going to have to share details of your configuration.
>
> On Tue, Sep 20, 2016 at 8:58 AM, Matthew Pounsett
> wrote:
>
>>
>>
>> On 16 September 2016 at 11:12, project722 wrote:
>>
>>> I have an interesting problem. I started noticing that when I do a dig
>
ember 2016 at 11:12, project722 wrote:
>
>> I have an interesting problem. I started noticing that when I do a dig
>> +trace against one of the domains we are authoritative for, we get errors
>> from our nameservers for "Bad Referral" and you can see where it forwarded
&g
On 16 September 2016 at 11:12, project722 wrote:
> I have an interesting problem. I started noticing that when I do a dig
> +trace against one of the domains we are authoritative for, we get errors
> from our nameservers for "Bad Referral" and you can see where it forwarded
&g
I have an interesting problem. I started noticing that when I do a dig
+trace against one of the domains we are authoritative for, we get errors
from our nameservers for "Bad Referral" and you can see where it forwarded
the request back up the namespace tree instead of giving
I would have to back port right now, and I have a work around that
will work until the we bump our fleet to a newer version. I was mostly
concerned about whether it was something in our network causing the
problem.
Thanks for all the help guys,
--Matt
On Thu, Feb 9, 2012 at 4:42 PM, Spain, Dr. J
> It's because a few load balancer vendors don't read freely available
> specifications but instead appear to reverse engineer the protocol and get it
> wrong.
> BIND 9.7.0 fixed a long standing of accepting glue promoted to answer by
> parent nameservers. Once we did that there was no need to
; > On 2/8/2012 10:32 PM, Matt Doughty wrote:
> >>
> >> I have spend the afternoon trying to figure this out. The response I
> >> get back from their nameserver looks fine to me, and dig +trace works
> >> fine, but a regular dig returns a servfail. I have looked a
PM, Matt Doughty wrote:
>>
>> I have spend the afternoon trying to figure this out. The response I
>> get back from their nameserver looks fine to me, and dig +trace works
>> fine, but a regular dig returns a servfail. I have looked at the code
>> for invalid response, but I
On 2/8/2012 10:32 PM, Matt Doughty wrote:
I have spend the afternoon trying to figure this out. The response I
get back from their nameserver looks fine to me, and dig +trace works
fine, but a regular dig returns a servfail. I have looked at the code
for invalid response, but I don't
131.107.125.65)
;; WHEN: Thu Feb 9 14:53:28 2012
;; MSG SIZE rcvd: 112
In message
, Matt
Doughty writes:
> I have spend the afternoon trying to figure this out. The response I
> get back from their nameserver looks fine to me, and dig +trace works
> fine, but a regular dig returns a
I have spend the afternoon trying to figure this out. The response I
get back from their nameserver looks fine to me, and dig +trace works
fine, but a regular dig returns a servfail. I have looked at the code
for invalid response, but I don't quite follow what is going on there,
and the co
On 1/24/2012 12:12 AM, Mark Andrews wrote:
It's a known bug.
Thanks for the update.
If you need a tester for a patch, just let me know.
Best,
KAM
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind
It's a known bug.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
b
On 1/23/2012 11:54 PM, Noel Butler wrote:
Likely because ns3 has only ipv6 address and no ipv4 address and the
server you are checking from has no ipv6 capability.
You are asking for big problems using this method.
You should give all NS records an IPv4 address, and then add in IPv6
on the on
On Mon, 2012-01-23 at 22:02 -0500, Kevin A. McGrail wrote:
> Hi All,
>
> On an older Bind server such as 9.3.6-p1, I can run dig +trace www.pccc.com.
>
> However, when I'm using 9.8.1-p1 and seeing a problem that stops the
> trace when it reaches our IPv6 nameserver,
Hi All,
On an older Bind server such as 9.3.6-p1, I can run dig +trace www.pccc.com.
However, when I'm using 9.8.1-p1 and seeing a problem that stops the
trace when it reaches our IPv6 nameserver, ns3.pccc.com. Examples follow.
Am I doing something wrong with the newer dig?
Regards
d a solution):
=20
dig +trace actually has another behaviour than doing the trace manually=
step by step with dig.
=20
=20
For a trace, dig is asking for the NS-records, then for the IP-address =
of the nameserver found and then go on asking this nameserver. Till the d=
estination is reached.
=2
ing exactly this, it is asking for the A-=
> >> record of root1. And of course I get the correct answer from named.
> >>> =20
> >>> The +trace option does not do this!
> >>> Instead, the +trace-option is using the searchsuffix in the resolv.conf=
> >>
On 9/1/2011 7:57 PM, Mark Andrews wrote:
In message<4e5fb1ab.4040...@data.pl>, Torinthiel writes:
On 09/01/11 17:56, Tom Schmitt wrote:
=20
I found the cause of my problem (and a solution):
=20
dig +trace actually has another behaviour than doing the trace manually=
step by step wi
the answer section of the responses by
>> default.
>> Try "dig +trace +additional".
>
> Hi Chris,
>
> you are right, thank you. With this I see the glue records:
>
> ; <<>> DiG 9.8.0-P4 <<>> +trace example.com
> ;; global op
Hi Tom,
At 23:42 01-09-2011, Tom Schmitt wrote:
But seriously: I don't see in the RFC that it is forbidden to have a
hostname directly in the root-zone (without a internal dot).
From RFC 921:
"The names are being changed from simple names, or globally unique
strings, to structured names,
> "dig +trace" calls getaddrinfo() and that needs to be able to resolve
> the hostname (without dots at the end). getaddrinfo() is called
> so that we don't have to have a full blown iterative resolver in
> dig.
>
I see. So no way to solve this one in dig itsel
> > In my case, dig is asking for the nameservers of the root-zone and is
> > getting the answer:
> > . IN NS root1
> > . IN NS root2
> > etc
> >
> > Next dig is asking for the A-record of root1. And here is the
> > differrence:
> >
> > If I do "dig root1" dig is asking exactly this, it is ask
In message <4e5fb1ab.4040...@data.pl>, Torinthiel writes:
> On 09/01/11 17:56, Tom Schmitt wrote:
> >=20
> > I found the cause of my problem (and a solution):
> >=20
> > dig +trace actually has another behaviour than doing the trace manually=
> step by st
On 09/01/11 17:56, Tom Schmitt wrote:
>
> I found the cause of my problem (and a solution):
>
> dig +trace actually has another behaviour than doing the trace manually step
> by step with dig.
>
>
> For a trace, dig is asking for the NS-records, then for the IP-addr
I found the cause of my problem (and a solution):
dig +trace actually has another behaviour than doing the trace manually step by
step with dig.
For a trace, dig is asking for the NS-records, then for the IP-address of the
nameserver found and then go on asking this nameserver. Till the
I spoke too soon :-(
>
> I think I found the reason why dig +trace always failed with a timeout.
> From the announcement of Bind 9.8.1 from earlier today:
>
> * If the server has an IPv6 address but does not have IPv6
>connectivity to the internet, dig
I think I found the reason why dig +trace always failed with a timeout.
From the announcement of Bind 9.8.1 from earlier today:
* If the server has an IPv6 address but does not have IPv6
connectivity to the internet, dig +trace could fail attempting to
use IPv6 addresses. [RT
> >> What strikes me as odd is that the first query does return 4 (internal)
> >> root servers, but no glue records ?
> >
> >I have no idea why this is this way.
>
> Because +trace only displays the answer section of the responses by
> default.
> Try &qu
. But this is no mistake, it's the intended architecture.
My DNS-server is an internal one without any conection to the internet. There
is no root hint file because I have a internal root zone on my own. And my root
servers have the glue records in this root zone and the NS records for the TLDs
On Aug 31 2011, Tom Schmitt wrote:
What strikes me as odd is that the first query does return 4 (internal)
root servers, but no glue records ?
I have no idea why this is this way.
Because +trace only displays the answer section of the responses by default.
Try "dig +trace +addit
18 AM
To: bind-users@lists.isc.org
Subject: Re: RE: what does dig +trace do?
>
> What strikes me as odd is that the first query does return 4 (internal)
> root servers, but no glue records ?
I have no idea why this is this way.
> Given those root name servers, do you have A-records
om. 10800 IN NS root4.
All these records I can query with dig without any problem, but dig +trace
still fails. :-(
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
your
root zone ?
Kind regards,
Marc Lampo
-Original Message-
From: Tom Schmitt [mailto:tomschm...@gmx.de]
Sent: 30 August 2011 01:57 PM
To: bind-users
Subject: what does dig +trace do?
Hi,
I have a question: What does dig +trace exactly do?
The reason for my question is:
I have a interna
Hi,
I have a question: What does dig +trace exactly do?
The reason for my question is:
I have a internal-only DNS in our company with my own root-zone. And normaly
all things are fine. But when there is an issue I would like to analyze with
dig +trace, the command fails.
If I do dig +trace
Hi
What I have found is that while dig +trace gets and displays the information
directly from the name servers along the way the resolver is also queried
and the resolver's result overrides the trace result. This can cause great
frustration as you see the trace looks correct but if the
On Jun 14, 2010, at 4:39 AM, Niall O'Reilly wrote:
On 12/06/10 10:48, Warren Kumari wrote:
So not awake, may be crazy...
wkum...@xxx~$ dig @ns1.dns-diy.com 35.com
; <<>> DiG 9.4.2-P2.1 <<>> @ns1.dns-diy.com 35.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<-
On 12/06/10 10:48, Warren Kumari wrote:
So not awake, may be crazy...
wkum...@xxx~$ dig @ns1.dns-diy.com 35.com
; <<>> DiG 9.4.2-P2.1 <<>> @ns1.dns-diy.com 35.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3253
;; flags: qr
On 12/06/10 04:41, ShanyiWan wrote:
[r...@flyinweb ~]# dig @ns1.dns-diy.com 35.com +trace
;<<>> DiG 9.7.0-P2<<>> @ns1.dns-diy.com 35.com +trace
; (1 server found)
;; global options: +cmd
;; Received 17 bytes from 218.85.139.33#53(218.85.139.33) in 2 ms
[r...@flyinweb ~]# dig @ns1.dns-diy.com
So not awake, may be crazy...
wkum...@xxx~$ dig @ns1.dns-diy.com 35.com
; <<>> DiG 9.4.2-P2.1 <<>> @ns1.dns-diy.com 35.com
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3253
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0
[r...@flyinweb ~]# dig @ns1.dns-diy.com 35.com +trace
; <<>> DiG 9.7.0-P2 <<>> @ns1.dns-diy.com 35.com +trace
; (1 server found)
;; global options: +cmd
;; Received 17 bytes from 218.85.139.33#53(218.85.139.33) in 2 ms
[r...@flyinweb ~]# dig @ns1.dns-diy.com 35.com
; <<>> DiG 9.7.0
On Apr 27, 2010, at 12:50 AM, Barry Margolin wrote:
In article ,
Warren Kumari wrote:
On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
What is happening is I suspect the DNS resolved IP given by my ISP
is
actually forwarding recursive queries to yet-another-server(s),
and is
introducing sl
In article ,
Warren Kumari wrote:
> On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
>
> > What is happening is I suspect the DNS resolved IP given by my ISP is
> > actually forwarding recursive queries to yet-another-server(s), and is
> > introducing slow name resolution and timeouts.
>
> Well, i
2010 3:14 PM
To: Lightner, Jeff
Cc: Josh Kuo; bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
On Apr 26, 2010, at 2:54 PM, Lightner, Jeff wrote:
I'm sure that's all it displayed when I went to it from my Windows
desktop's browser.
Uuuummm
Are you maybe
On 4/25/2010 12:01 AM, Josh Kuo wrote:
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 m
f the site.
-Original Message-
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Monday, April 26, 2010 3:14 PM
To: Lightner, Jeff
Cc: Josh Kuo; bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
On Apr 26, 2010, at 2:54 PM, Lightner, Jeff wrote:
> I'm
2010 2:20 PM
To: Lightner, Jeff
Cc: Josh Kuo; bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
On Apr 26, 2010, at 10:41 AM, Lightner, Jeff wrote:
?
That link only shows the IP you came from and does a reverse lookup
on
it. It doesn't seem to say anything about th
I'm sure that's all it displayed when I went to it from my Windows
desktop's browser.
-Original Message-
From: Warren Kumari [mailto:war...@kumari.net]
Sent: Monday, April 26, 2010 2:20 PM
To: Lightner, Jeff
Cc: Josh Kuo; bind-us...@isc.org
Subject: Re: dig +trace
nd-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
What is happening is I suspect the DNS resolved IP given by my ISP is
actually forwarding recursive queries to yet-another-server(s), and
is
introducing slow name resolution and tim
lf
Of Warren Kumari
Sent: Monday, April 26, 2010 10:29 AM
To: Josh Kuo
Cc: bind-us...@isc.org
Subject: Re: dig +trace to find all the forwarders?
On Apr 26, 2010, at 3:10 AM, Josh Kuo wrote:
> What is happening is I suspect the DNS resolved IP given by my ISP is
> actually forwarding recursive
nameserver you are
asking is the one doing the resolution, this *might* help you out:
http://www.damia.com/whatismydns/
W
In any case, I will
have to involve the ISP in troubleshooting and (hopefully) fixing the
problem. I was hoping there is some way to mimic "traceroute" with
"dig +t
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 wrote:
>
> On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
>
>
> You need administrative access to see the ove
On Apr 25, 2010, at 12:01 AM, Josh Kuo wrote:
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 m
In message , Jo
sh Kuo writes:
> > 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 lo
>
> 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.ne
In message , Jo
sh Kuo writes:
> Hi all,
>
> I am trying to trace a recursive outbound query. My workstation is
> configured to point to the forwarder/resolver 192.168.0.2, which is a
> dedicated forwarder that is configured to forward all DNS queries to the
> ISP's DNS resolver. Sometimes I get
Hi all,
I am trying to trace a recursive outbound query. My workstation is
configured to point to the forwarder/resolver 192.168.0.2, which is a
dedicated forwarder that is configured to forward all DNS queries to the
ISP's DNS resolver. Sometimes I get name resolution failures, and I want to
know
In message , Li
nux Addict writes:
>
> Hello Folks, I got a strange issue going on..
>
> I dig for a specific record against a ISP cache server , and the cache
> server doesn't seem to see it, but When I do dig +any, then the record stays
> in the cache for say 5minutes and then vanishes.
>
> an
Hello Folks, I got a strange issue going on..
I dig for a specific record against a ISP cache server , and the cache
server doesn't seem to see it, but When I do dig +any, then the record stays
in the cache for say 5minutes and then vanishes.
any idea?
~LA
___
ferent places on the Internet
able to duplicate the failure?
It's fixed in the next release. You should be able to verify this
using the v9_6 from the BIND Forum CVS repository.
I have the fix Mark refers to applied (the bug strikes during fallback
to TCP) and get:
$ dig +trace 231.84.192.i
ernet
> able to duplicate the failure?
It's fixed in the next release. You should be able to verify this
using the v9_6 from the BIND Forum CVS repository.
Mark
> dig +trace 231.84.192.in-addr.arpa
>
> ; <<>> DiG 9.6.1-P1 <<>>
On Wed, Sep 2, 2009 at 8:37 PM, Andris Kalnozols wrote:
> My 9.6.1-P1 dig programs (HP-UX and Linux) rather consistently fail
> when trying to trace the delegation of 231.84.192.IN-ADDR.ARPA.
> Out of curiousity, are others from different places on the Internet
> able to duplicate the failure?
Sam
My 9.6.1-P1 dig programs (HP-UX and Linux) rather consistently fail
when trying to trace the delegation of 231.84.192.IN-ADDR.ARPA.
Out of curiousity, are others from different places on the Internet
able to duplicate the failure?
dig +trace 231.84.192.in-addr.arpa
; <<>>
89 matches
Mail list logo
