So I'm been having dns issues for a while, differing issues that pop
up and I knock them down , but another just came to my attention which
has me stumped.
My external zone config has allow-recursion ( none; );
However I have some 3rd party sites that I CNAME too. Akamai for
example, yes CNAME to
Implementation specific, probably, but with Bind it's the authoritative
part that wins !
(assuming the caching name server is DNSSEC enabled, possibly even
validating DNSSEC, then)
If Bind is caching for all,
but authoritative for some domains (I think this is called : "bogus for
some domains"),
On 05/20/2011 05:56 AM, Matthew Pounsett wrote:
If, for some reason, you can't wait for your TTLs to expire, then
forwarding the relevant zones to your authoritative servers is a
better solution than slaving the zones.
How?
The whole point of stealth slaving is timely (NOTIFY/IXFR) updates of
On 05/20/2011 07:16 AM, Tory M Blue wrote:
This causes all types of failures if just using dig, or Linux built in
lookup mechanism, or heck Perl or PHP methods as well. None of the
stated methods, know that they should now query
cdn.domain.net.edgesuite.net, so they provide the CNAME and SERVFAI
On 19.05.11 23:16, Tory M Blue wrote:
> My external zone config has allow-recursion ( none; );
>
> However I have some 3rd party sites that I CNAME too. Akamai for
> example, yes CNAME to CNAME , i know I know :)..
>
> Well my primary NS servers will only provide the CNAME record:
>
> ;; QUESTIO
This is why people run separate views, separate instances, or separate
devices for DNS resolution (= recursive, by necessity) versus DNS
hosting (= non-recursive, best practice). If you run both hosting and
resolution on the same nameserver instance but different views, you may
need to be a lit
So, if I understand you correctly, if I were to sign my authoritative
zone and my caching nameserver, which is "bogus" for this zone, is
dnssec enabled, and also validating, and no other validating
nameserver is querying this bogus nameserver, then it's OK?
cv
On Thu, May 19, 2011 at 11:16 PM, Ma
> If, for some reason, you can't wait for your TTLs to expire, then forwarding
> the relevant zones to your authoritative servers is a better solution than
> slaving the zones.
>
But the server that is forwarding to the authoritative also caches the
response, so that won't help. I'm looking for
I found this on our list:
https://lists.isc.org/mailman/htdig/bind-users/2010-April/079653.html
Made more sense. :)
On 05/20/2011 08:41 PM, Noel Rocha wrote:
Hello,
I don't know if this is a problem ... but I found strange:
# date on server:
$ date
Fri May 20 20:31:23 BRT 2011
# key will
Hello,
I don't know if this is a problem ... but I found strange:
# date on server:
$ date
Fri May 20 20:31:23 BRT 2011
# key will be activated at 2011/05/20 20:35:00
$ dnssec-keygen -r '/dev/urandom' -a RSASHA1 -b 2048 -n ZONE -A
20110520203500 'mydomain.com'
Kmydomain.com.+005+48738
# Sh
In message , Carlos Vicente
writes:
> > If, for some reason, you can't wait for your TTLs to expire, then
> > forwarding the relevant zones to your authoritative servers
> is a better solution than slaving the zones.
> >
>
> But the server that is forwarding to the authoritative also caches th
On May 20, 2011, at 4:41 PM, Noel Rocha wrote:
> # Showing activate date
> $ cat Kmydomain.com.+005+48738.key | grep Activate
> ; Activate: 20110520203500 (Fri May 20 17:35:00 2011)
>
> This (20110520203500)2011/05/20 20:35:00 isn't "Fri May 20 17:35:00 2011." :(
>
> Anyone have idea how to solve
12 matches
Mail list logo
