The root servers no longer serve arpa or in-addr.arpa.
See the following for where to transfer these zones from
now. http://seclists.org/nanog/2011/Feb/1453
Mark
In message 4dfb848a.1080...@vr-web.de, Thomas Schweikle writes:
This is a MIME-formatted message. If you see this text it means
Yay! I fixed it! It was a problem with my router. I went to the Netgear
website, downloaded the latest firmware and BING! It's working now:
andy:~$ dig nhs.uk
; DiG 9.8.0-P2 nhs.uk
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 39092
;; flags: qr rd
In message banlktimo8lzvrqunvchctigkgzzb295...@mail.gmail.com, rams writes:
Hi ,
Can we resign a signed zone with out key files? Please clarify me.
No. The key files contain the private parts of the public/private
key pair.
Thanks,
Ramesh
--
Mark Andrews, ISC
1 Seymour St., Dundas
Am 18.06.2011 02:54, schrieb Mark Andrews:
The root servers no longer serve arpa or in-addr.arpa.
See the following for where to transfer these zones from
now. http://seclists.org/nanog/2011/Feb/1453
Arr! Seems I'd overlooked that ... :-(
I've corrected my config file. Now it works
On 6/17/2011 12:44 PM, Thomas Schweikle wrote:
!zone in-addr.arpa {
! type slave;
! file /var/cache/named/root/in-addr.arpa.slave;
! masters { 192.5.5.241; };
! notify no;
!};
You're configuring you server to be authoritative for the reverse DNS
zone. It's only going to have the reverse
Am 17.06.2011 23:29, schrieb Eivind Olsen:
Thomas Schweikle wrote:
But not reverse:
!user@ks1:~$ host 74.125.79.99
!Host 99.79.125.74.in-addr.arpa not found: 2(SERVFAIL)
...
!zone in-addr.arpa {
! type slave;
! file /var/cache/named/root/in-addr.arpa.slave;
! masters {
Hi!
I have set up a view for one site. It is bound to change answers as
necessary for different IP-ranges. It works as far as I could see.
But with one ip-range there is a problem ...
I can query internal addresses:
!user@kvm2~# host intweb.example.de
!intweb.example.de has address
On 18/06/2011 02:54, Mark Andrews wrote:
Actually, the root name servers still serve ARPA. They only dropped
IN-ADDR.ARPA earlier this year.
However, anyone who runs the kind of configuration that Thomas has
should be more vigilant. I would even recommend against slaving the root
zone and the
Greetings,
given my domain name is example.net, and my NS servers for example.net are:
ns1.example.com
ns2.example.com
But, example.com itself's NS servers are the registrator's (for
example, godaddy's).
Under this case, I don't need any glue for ns[1-2].example.com.
But why I still need to
Assume that bind 9.8.0 is in operation. A zone is configured with auto-dnssec
maintain, and the zone signing keys K and its successor K' are published.
Further assume that the activation time for K has passed and the zone is
properly signed with K. Now suppose that the activation time for K'
That is weird.
When I use my own NSes under my own domain, I need to reg them to .org
NSes, when I use my registrars NSes I don't.
There does not seem to be any technical reason for your scenario (imho).
Regards
-Sven
P.S.: A direct glue of course could reduce the lookup path length and save
On 06/18/11 09:30, Jorg W. wrote:
Greetings,
given my domain name is example.net, and my NS servers for example.net are:
ns1.example.com
ns2.example.com
But, example.com itself's NS servers are the registrator's (for
example, godaddy's).
Under this case, I don't need any glue for
On Sat, June 18, 2011 18:24, Lyle Giese wrote:
On 06/18/11 09:30, Jorg W. wrote:
Greetings,
given my domain name is example.net, and my NS servers for example.net
are:
ns1.example.com
ns2.example.com
But, example.com itself's NS servers are the registrator's (for
example, godaddy's).
On Sat, June 18, 2011 18:34, Lyle Giese wrote:
On 06/18/11 10:21, Sven Eschenberg wrote:
That is weird.
When I use my own NSes under my own domain, I need to reg them to .org
NSes, when I use my registrars NSes I don't.
There does not seem to be any technical reason for your scenario
On 6/18/2011 12:24 PM, Lyle Giese wrote:
On 06/18/11 09:30, Jorg W. wrote:
Greetings,
given my domain name is example.net, and my NS servers for
example.net are:
ns1.example.com
ns2.example.com
But, example.com itself's NS servers are the registrator's (for
example, godaddy's).
Under this
On 06/18/11 10:26, David Miller wrote:
All domains, at every level, have to configure their records such that
the tree can be walked from root to their domain.
Follow the .s.
For: this.long.chain.example.com.
com. must be delegated by .
example.com. must be delegated by com.
On Jun 18 2011, Michael Sinatra wrote:
In theory, you can insert glue records anywhere above the zone in
question. See RFC 2181, section 5.4.1.
As an example, glue for the servers adns1.berkeley.edu and
adns2.berkeley.edu exist in the root zone.
For fj, hk, and xn--j6w193g. These are
On 06/18/11 15:23, Chris Thompson wrote:
On Jun 18 2011, Michael Sinatra wrote:
In theory, you can insert glue records anywhere above the zone in
question. See RFC 2181, section 5.4.1.
As an example, glue for the servers adns1.berkeley.edu and
adns2.berkeley.edu exist in the root zone.
For
2011/6/19 Michael Sinatra mich...@rancid.berkeley.edu:
On 06/18/11 15:23, Chris Thompson wrote:
Of course, at the root zone level, *all* NS records need either
required glue or sibling glue, because every single one of them
is somewhere under the root zone. At least, until the aliens contact
2011/6/19 David Miller dmil...@tiggee.com:
In the particular case of the OP - example.net. has name servers under
example.com.
To make lookups for records under example.net., resolvers walk the tree from
. to net. and get NS records - ns1.example.com. and ns2.example.com.
You can't insert
On Sat, Jun 18, 2011 at 4:22 PM, Michael Sinatra
mich...@rancid.berkeley.edu wrote:
Consider:
baz.org. NS ns1.dns.podunk.edu.
baz.org. NS ns2.dns.podunk.edu.
and
dns.podunk.edu. NS ns1.dns.podunk.edu.
dns.podunk.edu. NS ns2.dns.podunk.edu.
In theory, you should only need glue in
21 matches
Mail list logo
