> > '_' is an illegal character in hostnames in the DNS...
>
> Yeah, I got hosed by that one by a consultant.
MCSE per chance? [Sorry; couldn't resist.]
-JP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
fro
Hello,
1) the dig command, as shown, does not ask an authoritative name server
for eeoc.gov.
but rather addresses a locally configured caching name server
(10.120.11.107).
(which may explain the difference in size - 1726 bytes -
as opposed to the 3918 bytes of Doug Barton)
((some data
In message <798e3caf2fcc264481d8f75fb3d0bfd91b538...@mailmbx10.mail.la.gov>, Br
ad Bendily writes:
>
> When trying the DNSSEC check command from:
> https://www.dns-oarc.net/oarc/services/replysizetest
>
> behind our corporate firewall, I get:
> rst.x476.rs.dns-oarc.net.
> rst.x485.x476.rs.dns-oa
Matthew wrote on 09/23/2011 03:21:06 AM:
> On 23/09/2011 00:39, Joachim Tingvold wrote:
> > Or replace :: with _,
>
> '_' is an illegal character in hostnames in the DNS...
Yeah, I got hosed by that one by a consultant.
How about replace all : with a -. :: becomes --. No rule against that,
Maybe some of the links mentioned here will help you...
https://www.dnssec-deployment.org/index.php/deployment-case-studies/dnssec-why-threats/
bb
> -Original Message-
> From: bind-users-bounces+brad.bendily=la@lists.isc.org
> [mailto:bind-users-bounces+brad.bendily=la@lists.is
On 09/27/2011 13:45, Brad Bendily wrote:
> dig +dnssec eeoc.gov
Try that again with +notcp.
FYI, on a "clean" network the response I get to that query is 3,918 bytes.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadt
When trying the DNSSEC check command from:
https://www.dns-oarc.net/oarc/services/replysizetest
behind our corporate firewall, I get:
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"Tested at 2011-09-27 20:32:34 UTC"
"205.172.49.177 sent EDNS buffer s
On 9/27/11 1:15 PM, "Warren Kumari" wrote:
> On Sep 27, 2011, at 3:52 PM, Tom Schmitt wrote:
>> I tested "rndc reload" against "rndc reconfig" on five differrent servers,
>> Solaris and Linux, 9.8.0 and 9.4.1. On all servers the same result:
>> Both commands take roughly the same amount of time! S
On Sep 27, 2011, at 3:52 PM, Tom Schmitt wrote:
>
>> In this case "rndc reconfig" should be sufficient. This command tells
>> BIND to re-read config file and load all new zones without touching
>> any previously loaded zones.
>
> This was my understanding (after reading the text from rndc) as w
>
> The odd part is that both NS3 and NS4 weren't able to request ixfr
> transfers.
> Shouldn't allow-transfer cover these kind of transfer requests as well?
>
First: Do you have statements "provide ixfr;" and "request ixfr;" in your
config?
Second: To do a ixfr a server is first sending a
> In this case "rndc reconfig" should be sufficient. This command tells
> BIND to re-read config file and load all new zones without touching
> any previously loaded zones.
This was my understanding (after reading the text from rndc) as well.
But to my surprise:
I tested "rndc reload" against "r
On Tue Sep 27 2011 at 17:32:22 CEST, Issam Harrathi wrote:
> and you say here it's cached for 30 seconds?!
Evan said:
> and we've discussed implementing it in BIND9, but haven't had time yet.
In other words, they are *not* cached in BIND9.
-JP
__
Actually he said the DNS protocol allows for it and ISC had been considering
adding it.
-Ben Croswell
On Sep 27, 2011 11:38 AM, "Issam Harrathi" wrote:
> As i test it's not cached at all, and you say here it's cached for 30
> seconds?!
> i'm using 9.7.2-P3.
>
> 2011/9/27 Evan Hunt
>
>> > I disco
As i test it's not cached at all, and you say here it's cached for 30
seconds?!
i'm using 9.7.2-P3.
2011/9/27 Evan Hunt
> > I discover that servfail are not cached. is it normal?
>
> Yes, that's normal.
>
> Temporary negative caching of SERVFAIL responses for a limited period (up
> to 30 seconds
> I discover that servfail are not cached. is it normal?
Yes, that's normal.
Temporary negative caching of SERVFAIL responses for a limited period (up
to 30 seconds, if I recall correctly) is permitted by the DNS protocol,
and we've discussed implementing it in BIND9, but haven't had time yet.
-
I recently observered a rather strange phaenomenon.
By accident I have configured a nameserver to allow queries from NS1 and NS2
and allow transfers from NS3 und NS4.
So far so good...
Naturally NS1 and NS2 could do all kinds of queries but no zone transfers.
NS3 and NS4 weren't allowed to ask
2011/9/27 Tom Schmitt :
>
>
>> It is not clear in your question, are you use "rndc reload" or "rndc
>> reload zone.name"? Latter will be faster in case if you change one or
>> few zones in one pass of your updating-script.
>
> I generate from my database the complete named.conf, especially includin
I discover that servfail are not cached. is it normal?
explanation:
I have a cache-recursing server and i try www.blabla.com (which exist) and
then i stop the dns server of www.blabla.com. Then (after ttl expired) from
my cache-recusing server i try dig @0 www.blabla.com and i receive a
servfail, a
> It is not clear in your question, are you use "rndc reload" or "rndc
> reload zone.name"? Latter will be faster in case if you change one or
> few zones in one pass of your updating-script.
I generate from my database the complete named.conf, especially including new
zones and then trigger a
2011/9/27 Tom Schmitt :
>
>> > I just updated a couple of my DNS-servers from the rather old version
>> > 9.4.1 to a newer version 9.8.0-P4.
>> >
>> > After this I have problem with outages. Looking into it, I found that
>> > the time for a "rndc reload" has nearly doubled!
>>
>> This has been poin
> > I just updated a couple of my DNS-servers from the rather old version
> > 9.4.1 to a newer version 9.8.0-P4.
> >
> > After this I have problem with outages. Looking into it, I found that
> > the time for a "rndc reload" has nearly doubled!
>
> This has been pointed out to me before; do you re
--- On Mon, 9/12/11, Kevin Darcy wrote:
> You should either a) pursue with your network hardware
> vendor why its device is responding to a query to the SRAA
> with a different source address, thus breaking the rules of
> DNS resolution, or b) select a working resolver address in
> the Global Uni
22 matches
Mail list logo
