Mark Andrews wrote:
> In message <528ec4db.6060...@hpl.hp.com>, Andris Kalnozols writes:
>> Hi, Mark.
>>
>> I've also seen the same problem which occurs with AXFR queries
>> to both Windows server 2003 and 2012:
>>
>> Win2003
>> ---
>
Hi, Mark.
I've also seen the same problem which occurs with AXFR queries
to both Windows server 2003 and 2012:
Win2003
---
> ;; Got bad packet: extra input data
> 115 bytes
> e9 f3 80 80 00 01 00 01 00 00 00 00 04 6c 61 62 .lab
> 73 03 68 70 6c 02 68 70 03 63 6f 6d 00 00
Hi.
Although not a BIND-related issue, I would like to ask if someone could
explain the conditions under which a compiled C program on Linux could
be made to have a name resolution dependency on the settings within the
file `/etc/host.conf'. As I understand things, host.conf is the ancestor
of t
On 7/22/2012 10:19 AM, Paul Wouters wrote:
(I don't think this made it to the list before, mixup of email addresses)
Please consider including this patch,
Paul
-- Forwarded message --
Date: Mon, 2 Jul 2012 17:45:08
From: Paul Wouters
Cc: Paul Vixie
To: bind-users@lists.isc.o
No arguments from me on that reality check. I'm just glad there is a
"Plan B" while waiting for vendors and/or corporate IT to attend to
these details.
--
Andris
On 6/11/2012 3:17 PM, Kevin Darcy wrote:
At the risk of exceeding my cynicism quota for the week, this is an
Active Directory cl
On 6/11/2012 2:54 PM, Mark Andrews wrote:
Andris,
you should also be pushing for proper multi-homed server
support in those applications that are causing you problems (read
just about all IP applications). This is relatively easy for TCP.
https://www.isc.org/community/blog/201101/how-to-co
On 6/11/2012 1:23 PM, Kevin Darcy wrote:
**Configure sortlists to push those bad A records to the end of the
response. This may on the surface seem like a kludge, but remember, the
whole point of sortlists is to give preference to certain addresses over
others, and IMO, a working/reachable addres
I have the following issue:
* A domain name which our organization does not control is used
for authentication. It returns 40 A records which point to
various MS Active Directory servers throughout the company.
* A few of these A records point to non-functioning hosts and
cause
> The Dependence Walker utility says that MSVCR80.DLL can
> not be resolved...
After my original post, I ran Dependence Walker against the
dig.exe that runs fine on my Win7 64-bit laptop and inspected
the properties of the MSVCR80.DLL library to which it linked.
The Details tab showed:
Product
I just built a Windows 7 64-bit system and did the following
steps to make the `dig' program available for use:
* opened ftp://ftp.isc.org/isc/bind9/9.8.0-P2/BIND9.8.0-P2.zip
* copied dig.exe and the DLL files to a folder
* added the folder's path to the system's PATH environment variable
T
> I using bind 9.7.3 as resolver in a slightly larger server farm with
> some mail servers that use domain key validation.
> If a try
>
> # host -t TXT _adsp._domainkey.federalreserve.gov
>
> bind dies with
>
> May 26 19:59:02 resolv04 named[8237]: buffer.c:285: REQUIRE(b->used + 1
> <= b->lengt
RFC 2181, section 9, indicates that name servers should not set
the TC bit gratuitously; as long as the answer section is complete,
TC should not be set just because the authority and/or additional
sections won't also fit in the UDP packet.
Using BIND (9.4.3-P3 and 9.7.2-P3) as a resolver doesn't
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
; <<>> DiG 9.6.1-P1 <<>> +trac
> From: "Mike Bernhardt"
>
> We use h2n to generate our db files, but NOT to generate named.conf. We
> recently add the network 10.160.0.0:255.240.0.0 to h2n, which then generated
> db.10.160, db.10.161, etc.
>
> All of these 16-bit networks will reside in the same zone. Is there a way to
> eith
14 matches
Mail list logo
