On 11.03.10 08:54, Gilles Massen wrote:
Obviously there are parallels to NXDOMAIN rewriting. However, the major
difference I see is that NXDOMAIN is a clear message, known by the OSs
and applications, that has basically one meaning. SERVFAIL is more like
'didn't work. go figure.' And the good
In message 4b98a1a6.9070...@restena.lu, Gilles Massen writes:
Mark, Mat,
Mat wrote:
End users will get confused by this, but then there are plenty of
other possibilities with and without DNS they may get confused about.
I think providing help to them should be dealt with by the OS
Gilles Massen wrote:
As soon as applications (or local stub resolvers) are validating, that
would be the place to generate a user compatible error. But in the
best case this will take years. In the mean term we are stuck with dummy
users, and ISPs that might want to enable validation, but
On 03/10/10 11:59, Chris Thompson wrote:
On Mar 10 2010, Sam Wilson wrote:
In article mailman.750.1268169970.21153.bind-us...@lists.isc.org,
jcarrol...@cfl.rr.com wrote:
dig was added to Solaris 9. It is not native to Solaris 8 or older.
That would explain why it's only where Chris found
Mark Andrews wrote:
Obviously there are parallels to NXDOMAIN rewriting. However, the major
difference I see is that NXDOMAIN is a clear message, known by the OSs
and applications, that has basically one meaning. SERVFAIL is more like
'didn't work. go figure.' And the good thing is that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When using split view, can one point to the same file in both views?
example:
view blah-internal {
match-clients { internal-users; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone
Yes, assuming you want them to both have the same zone data.
We use a naming convention so we know when we're sharing a file. Each
view gets their zonefiles with -viewname (ie: example.com-internal)
appended. Common zones get -common. This keeps us from modifying the
wrong file, and lets us
I tried this and noticed that the first view will IXFR the file from the
master, then the second view will try to IXFR and fail because the file
has already been updated. Then the second view does a complete AXFR. I
ended up with errors in the log file. With busy DDNS zones the errors
were very
On 11.03.10 10:06, Jason Gates wrote:
When using split view, can one point to the same file in both views?
for master zones, yes, but you will have to reload it in all views
explicitly (I think that server reload should take care of that)
for slave zones, I'm afraid it's not possible. You will
I too found it best to have them be separate even if they contain the
same data. For me I had an internal and external view - the external
was my original zone so I made that my external view then simply
prepended internal- to the zone file name in the internal view. That
way all my intenal
Hi Kevin,
I followed your advice and I explicitly added:
recursion yes;
allow-recursion { custnets; };
I'm using MRTG for interface bandwidth monitoring and Smokeping for time
response on queries and all look the same as before. So, so far so good!
Thank you!
Julian
- Original
On Thu, 11 Mar 2010, Matus UHLAR - fantomas wrote:
On 11.03.10 10:06, Jason Gates wrote:
When using split view, can one point to the same file in both views?
for master zones, yes, but you will have to reload it in all views
explicitly (I think that server reload should take care of that)
aihua zhang wrote:
[...]
the BIND version is BIND-9.6.1,my install process is :./configure;make
;make install, is there any wrong with my install or others problem ?
thanks!
Dynamic updates work correctly in an IPv6 environment to the best of my
knowledge, however, nsupdate does not at this
In message 4b98fd2d.5080...@restena.lu, Gilles Massen writes:
Mark Andrews wrote:
Obviously there are parallels to NXDOMAIN rewriting. However, the major
difference I see is that NXDOMAIN is a clear message, known by the OSs
and applications, that has basically one meaning. SERVFAIL is
DLV records for TLD's signed using RASSHA256 (and RSASHA512)
will be added DLV.ISC.ORG in the next few days.
BIND 9.6.0 and BIND 9.6.0-P1 do not correctly handle these
records and it is recommended that you upgrade to BIND 9.6.1
or later. This was
Some suggestions:
1) always use -d with nsupdate, otherwise you get almost no indication
of what it's doing under the covers
2) look in your query logs to see what queries nsupdate is generating
3) when you say change [...] to IPv6 environment, am I to understand
that you're actually bringing up
On 3/11/2010 2:54 AM, Gilles Massen wrote:
Mark, Mat,
Mat wrote:
End users will get confused by this, but then there are plenty of
other possibilities with and without DNS they may get confused about.
I think providing help to them should be dealt with by the OS instead
of bloating DNS.
Yes and no.
Yes for static masters.
No for everything else, i.e. slaves, dynamic masters, stubs.
Mark
-
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users
In message af5cd12999f848089ceada384be2e...@internal.corp.ds, ic.nssip writ
es:
I had some problems with versions prior 9.7.0, when the response time =
dramatically increased for hours after two or 3 days after cache reached =
the maximum size in the memory. I used to restart named process and
In article mailman.792.1268343500.21153.bind-us...@lists.isc.org,
Mark Andrews ma...@isc.org wrote:
No. It's I've tried real hard to get you a answer which is not a
forgery but I can't.
Not really. It's I've tried real hard to get you an answer that I can
*tell* is not a forgery, but I
Kevin Darcy wrote:
The fundamental requirement is that the requestor needs to know that
their query FAILED. When you send back a helpful, answerful response
for a failure, either under NXDOMAIN redirection or your proposal, then
you essentially deceive the client and confuse any
21 matches
Mail list logo
