On Mon, Jan 25, 2010 at 07:12:50PM +0100, Frank Stanek wrote:
> Thank you for your reply.
>
> > the browser apparently needs to resolve the IP before itdesides whether to
> > use proxy or not. It may be a problem of the .pac file.
>
> I have also suspected the pac file some time ago. We have trie
Jack Tavares wrote:
> Looking at the code for libbind, specifically
> res_nmkupdate,
> there is no case statement for RRSIG records.
>
> In this case, I was trying to update the TTL.
> Is that not allowed intentionally?
I think so. The TTL of a RRSIG RR *MUST* match the TTL value of the
RRset i
On 1/25/2010 2:47 PM, Niall O'Reilly wrote:
Frank Stanek wrote:
I'm sorry but I don't quite understand what you mean. Could you
please elaborate this on the basis of this excerpt from our pac
file?
function FindProxyForURL(url, host)
{
var proxy1 = "PROXY 192.168.240.29:8080";
var proxy
Looking at the code for libbind, specifically
res_nmkupdate,
there is no case statement for RRSIG records.
In this case, I was trying to update the TTL.
Is that not allowed intentionally?
Thank you
--
Jack Tavares
"How many more can we sell with this button?"
Frank Stanek wrote:
I'm sorry but I don't quite understand what you mean. Could you
please elaborate this on the basis of this excerpt from our pac
file?
function FindProxyForURL(url, host)
{
var proxy1 = "PROXY 192.168.240.29:8080";
var proxy2 = "PROXY 172.16.1.30:8080";
if ( dnsDom
Thank you for your reply.
> the browser apparently needs to resolve the IP before itdesides whether to
> use proxy or not. It may be a problem of the .pac file.
I have also suspected the pac file some time ago. We have tried
to use !(isResolvable(host)) to try and make the browser give up
faster,
On 2009-12-10 08:49, Niobos wrote:
Thank you very much for your help; I'll forward the conversation to the
bug-tracking list.
Since these are my first DNSSEC experiments, I just wanted to make sure that it
wasn't a problem with my understanding of the concept.
Niobos
This has been confi
On 25.01.10 17:14, Frank Stanek wrote:
> we want to set up a DNS server (bind-9.4.3-P3) for the internal LAN only.
> However for security reasons we need to only allow a few trusted systems
> to resolve external host names (ie names we are not authoritative for):
> * Trusted systems can resolve nam
Hello,
we want to set up a DNS server (bind-9.4.3-P3) for the internal LAN only.
However for security reasons we need to only allow a few trusted systems
to resolve external host names (ie names we are not authoritative for):
* Trusted systems can resolve names from our zones _and_ external names
Hi,
I have a problem about the DDNS ,When I nsupdated the master dns server
under with dnssec,but it failed as following:
*r...@root:/var/named/chroot/etc# nsupdate -d
> server 192.168.225.130 5353
> update add test.net 900 A 5.5.5.5
>
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status
Yes, of course, at least they needs to know nameservers for that zone.
http://ripe.net/rs/reverse/reverse_howto.html
2010/1/25 Alans
> I’m new with this ISP, but I don’t think they requested that.
>
> Your point is RIPE won’t give delegations without request, right?
>
>
>
> Regards,
>
> Alans
I'm new with this ISP, but I don't think they requested that.
Your point is RIPE won't give delegations without request, right?
Regards,
Alans
From: bind-users-bounces+batpower83=yahoo.co...@lists.isc.org
[mailto:bind-users-bounces+batpower83=yahoo.co...@lists.isc.org] On Behalf
Of Peter
Have you requested delegation?
2010/1/25 Alans
> Hello,
>
> When I check our dns ip from external server for ptr records it shows
> nothing but
> 93.in-addr.arpa.6562IN SOA ns-pri.ripe.net.
> dns-help.ripe.net. 2010012534 3600 7200 1209600 7200
> We bought 93.x.x.0/x from RI
Hello,
When I check our dns ip from external server for ptr records it shows
nothing but
93.in-addr.arpa.6562IN SOA ns-pri.ripe.net.
dns-help.ripe.net. 2010012534 3600 7200 1209600 7200
We bought 93.x.x.0/x from RIPE, does that mean that RIPE didn't delegate
93.x.x.0/x to us?
14 matches
Mail list logo
