> For my part, I'd be curious to know what sort of problem
> you're trying to solve with dig.
Oh, I solved it. I was getting different data for my parent
zone depending where I queried from, but the differences
didn't match what I expected based on an internal/external view
classification of the
Hi binders,
What would cause a query to not show in any logs on BIND 9.10.2-p2, seems
9.10.2-p2 is not receiving
Queries tcpdump shows the query's getting in but bind does not show the same
incoming query in its
logs, Therefore no response is returned ID8 shows this.
Load on dns server i
For my part, I'd be curious to know what sort of problem you're trying to
solve with dig. We might be able to shed a little more light on what the
best command would be for you.
The +recurse gets overridden when you use +trace:
+[no]recurse
... Recursion is automatically disabled when
In message <559dbe9b.8000...@lancaster.ac.uk>, Graham Clinch writes:
> Hi Carl,
>
> > I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on
> > a machine with a pppoe link with an mtu of 1492. The routers seem to be
> > properly fragmenting udp - it can receive large packets suc
Mark Andrews responds to my suggestion:
>> [...] the "+trace"
>> option essentially overrides the @server specification, except for
>> the initial query for the root zone nameservers. [...]
>>
>> Is my understanding correct?
>>
>> If it is, it might be helpful to add a quick note to the "dig"
Hi Carl,
I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on
a machine with a pppoe link with an mtu of 1492. The routers seem to be
properly fragmenting udp - it can receive large packets such as
dig www.byington.org +dnssec +bufsiz=4000 +notcp @205.147.40.34
which says:
1) status REFUSED - server with recursion turned off. with or without
+norecurse on the dig command.
2) status NXDOMAIN - server with recursion turned on with or without
+norecurse on the dig command (and access to the internet in my case)
3) status may be NOERROR depending on if a forwarder can re
Hi:
Up until this point I have configured bind to serve a single domain (zone)
and the bind server itself (the nameserver) lived on that domain. As an
example the server was ns.domain1.com and was the authoritative server for
domain1.com.
I am in a situation where I need to configure bind to serv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a client with 9.10.2-P1-RedHat-9.10.2-2.P1.fc22 on Fedora 22, on
a machine with a pppoe link with an mtu of 1492. The routers seem to be
properly fragmenting udp - it can receive large packets such as
dig www.byington.org +dnssec +bufsiz=4000 +
In message <13180.1436394...@vindemiatrix.encs.concordia.ca>, Anne Bennett writ
es:
>
> I've been trying to debug a problem with dig, and it has finally
> occurred to me that, if I understand this correctly, the "+trace"
> option essentially overrides the @server specification, except for
> the i
I've been trying to debug a problem with dig, and it has finally
occurred to me that, if I understand this correctly, the "+trace"
option essentially overrides the @server specification, except for
the initial query for the root zone nameservers. (I was using
"+showsearch +trace +recurse".)
Is m
On Wed, Jul 08, 2015 at 05:38:59PM +0200,
stefan.las...@t-systems.com wrote:
> Mark Andrews:
> >> By default, the bind daemon uses the "relative" style (or
> >> something similar) when writing dynamic zone files to disk.
> >> Guess what... all those "$ORIGIN" lines make it more difficult
> >>
Does this nameserver have direct access to the Internet root nameservers? If
not, does it have forwarding enabled?
If the answer to both of those is "no", then a timeout is the expected
behavior; that's what you get when you try to query nameservers that you can't
reach.
In article ,
Harshith Mulky wrote:
> Hello,
> I have a query here,
> I have named.conf configured But I do not have zone file configured for a
> domain name as "e164.ld"
> I am sending out a query asdig @
> 8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR
> ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <
It's possible to use TSIG keys to match views. So you could do the zone
transfers with different TSIG keys and get different versions of the same zone.
- Kevin
-Original Message-
From: bind-users-boun...@lis
>> By default, the bind daemon uses the "relative" style (or something
>> similar) when writing dynamic zone files to disk.
>> Guess what... all those "$ORIGIN" lines make it more difficult to
>> parse the f ile by a separate script... ;)
> Truly, you don't wan't to be reading master files. If
In message , stefan.las...@t-systems.com writes:
> Hi,
>
> the "named-compilezone" tool can output zone files in two different styles (u
> sing the -s option):
> "full" (suitable for processing by a separate script)
> "relative" (more human-readable)
>
> By default, the bind daemon uses
Hi,
the "named-compilezone" tool can output zone files in two different styles
(using the -s option):
"full" (suitable for processing by a separate script)
"relative" (more human-readable)
By default, the bind daemon uses the "relative" style (or something similar)
when writing dynamic
Hello,
I have a query here,
I have named.conf configured But I do not have zone file configured for a
domain name as "e164.ld"
I am sending out a query asdig @ 8.7.9.8.6.0.3.6.6.9.1.e164.ld.
NAPTR
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>>
8.7.9.8.6.0.3.6.6.9.1.e164.ld. NAPTR;; global
19 matches
Mail list logo
