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?
Have you requested delegation?
2010/1/25 Alans batpowe...@yahoo.co.uk
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
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 batpowe...@yahoo.co.uk
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?
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:
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
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 names
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
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,
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 (
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 proxy2
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 it
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 tried
to
12 matches
Mail list logo
