I have created a static zone file for www.abcd.com with the Answer section
entries containing 2 IP addresses like 1.1.1.1 and 2.2.2.2. I tried to print
these addresses in the towiresorted function for the random order like -
for(i=0;icount;i++)
{
char adstr[40];
In message banlktimxqxzfurpp9jggga9xvhsb72k...@mail.gmail.com, Jon F.
writes:
You know I was thinking and I guess the original poster could
actually do the zone mimicking by just adding the .us zone statement
to named.conf but point it to the same zone name as the already
built zone. In the
Hello,
Please see this reference:
$ dig mydots.net @j.gtld-servers.net
; DiG 9.4.2-P2.1 mydots.net @j.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41902
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;;
Hi All,
i have a private Network with a Debian Lenny Server/Router and the
Services BIND9.7.3(DDNS)/DHCP4.1.1/PPPOE3.8/CUPS1.4.4/APACHE2.2.16 and
Kernel 2.6.37.2.
My Problem is that he can not resolve himself and regardless from which
PC i do a ping i can not resolve my two
Correction, my server can see himself localy, for example:
feld-server:/var/www# ping -R -c 1 feld-server
PING feld-server.feldland.lan (192.168.0.186) 56(124) bytes of data.
64 bytes from feld-server.feldland.lan (192.168.0.186): icmp_req=1
ttl=64 time=0.090 ms
RR: feld-server.feldland.lan
On 07/01/11 05:02, Markus Feldmann wrote:
Hi All,
i have a private Network with a Debian Lenny Server/Router and the
Services BIND9.7.3(DDNS)/DHCP4.1.1/PPPOE3.8/CUPS1.4.4/APACHE2.2.16 and
Kernel 2.6.37.2.
My Problem is that he can not resolve himself and regardless from which
PC i do a ping i
On 07/01/11 03:47, Jeff Peng wrote:
Hello,
Please see this reference:
$ dig mydots.net @j.gtld-servers.net
; DiG 9.4.2-P2.1 mydots.net @j.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 41902
;; flags: qr rd; QUERY: 1, ANSWER: 0,
Am 01.07.2011 14:51, schrieb Lyle Giese:
Markus,
To be sure, you know that nslookup and dig do NOT use the search
parameter in /etc/resolv.conf. So when you do an nslookup or dig query,
you have to use the fully qualified domain name(FQDN).
PING uses the search parameter in /etc/resolv.conf, so
I set up a zone with dnssec, and wanted to verify that it was working
properly. But I appear to have trouble with the root KSK.
$ dig +dnssec danmcdonald.us +topdown
;; No trusted key, +sigchase option is disabled
; DiG 9.7.3-P1 +dnssec danmcdonald.us +topdown
I appear to have the
On 07/01/11 08:50, Markus Feldmann wrote:
Am 01.07.2011 14:51, schrieb Lyle Giese:
Markus,
To be sure, you know that nslookup and dig do NOT use the search
parameter in /etc/resolv.conf. So when you do an nslookup or dig query,
you have to use the fully qualified domain name(FQDN).
PING uses
Daniel McDonald dan.mcdon...@austinenergy.com wrote:
I set up a zone with dnssec, and wanted to verify that it was working
properly. But I appear to have trouble with the root KSK.
$ dig +dnssec danmcdonald.us +topdown
;; No trusted key, +sigchase option is disabled
Any advise as to what
Yes, all my zones are (or will be) signed. And all are dynamic update;
tricks like pointing all zones to the same zone files don't work.
So the bottom line is that either way I would somehow need to get my
registrar(s) to put special records (DNAME or BNAME if it escapes the
politics) into the
Yes, the example.us zone loads. As I mentioned, no errors in named.log, and
the statistics webserver (in named) shows example.us as active, albeit with
'-' for the serial number instead of the number in the zone file.
How did you get a DNAME into .com?
I did make example.us a zone - it is
On 07/01/2011 10:03, Timothe Litt wrote:
Yes, all my zones are (or will be) signed. And all are dynamic update;
Then the answer is simple, have a front end that allows you to make the
edits in one place and have them updated in both zones.
--
Nothin' ever doesn't change, but
Am 01.07.2011 18:35, schrieb Lyle Giese:
You are right in that you only need one host at dyndns.org to update
your ip address, but you want to have two different websites. The proper
way to do that is with CNAME entries pointing to the host you are
updating at connect time.
Do i need to open my
h.gtld-servers.net is one of the net domain's NS servers.
As the info below:
$ dig mydots.net @h.gtld-servers.net
; DiG 9.4.2-P2.1 mydots.net @h.gtld-servers.net
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 57902
;; flags: qr rd; QUERY: 1,
On 7/1/11 9:31 PM, PANG J. wrote:
Why the net zone has the glue for the servers which are in the com
zone?
skull@mithrandir:~$ dig ns com +short | sort
a.gtld-servers.net.
b.gtld-servers.net.
c.gtld-servers.net.
d.gtld-servers.net.
e.gtld-servers.net.
f.gtld-servers.net.
g.gtld-servers.net.
Those aren't glue records for a .com zone. Those glue records are for
mydots.net, the NS' just so happen to be residing in the .com zone. The name
servers don't have to be in the same zones as the actual domain name. On a
side note, the gtld's cover .com as well.
On Fri, Jul 1, 2011 at 2:31 PM,
On 07/01/11 14:13, Markus Feldmann wrote:
Am 01.07.2011 18:35, schrieb Lyle Giese:
You are right in that you only need one host at dyndns.org to update
your ip address, but you want to have two different websites. The proper
way to do that is with CNAME entries pointing to the host you are
that's meaningless.
net and com are different zones, though they are located in the same
servers.
于 2011-7-2 3:48, Emanuele Balla (aka Skull) 写道:
On 7/1/11 9:31 PM, PANG J. wrote:
Why the net zone has the glue for the servers which are in the com
zone?
skull@mithrandir:~$ dig ns com
On Fri, Jul 1, 2011 at 12:31 PM, PANG J. pa...@xuite.net wrote:
http://h.gtld-servers.netWhy the net zone has the glue for the servers
which are in the com zone?
Glue refers to address records for name servers of delegated child zones,
when the names of those servers are subdomains of the
于 2011-7-2 5:47, Casey Deccio 写道:
However, records in the additional section don't always correspond to
glue records contained in the delegating zone. Servers may also return
records from other sources in their additional section, such as from
other zones for which they are authoritative. Such
When DNAME was being developed the working group had to make a
decision about whether DNAME should redirect the node it was at or
just the names below it. The decision was made to do the latter
because it didn't require TLD operators to know about DNAME at the
cost of a little more work to keep
23 matches
Mail list logo