On 07.02.12 14:10, Lightner, Jeff wrote:
Virtualization doesn't reduce use of resources but DOES separate into
what are perceived to be multiple "servers" so I'm not sure what you
mean by "you still have one server".
one machine, one piece of hardware. There's not much to separate there,
unle
Hi, thanks for the quick answer,
but my problem is still not resolved, i check all your solutions but
nothing.
I'll show you my file zone which i wanted to sign and the command i used.
My file zone:
; This is a zone-signing key, keyid 12762, for *../etc/toto.com.*
; Created: 20120207101131 (Tue
Searching the title of the vulnerability with google results one PDF document.
http://www.google.co.jp/#q=Ghost+Domain+Names:+Revoked+Yet+Still+Resolvable+PDF
It shows details.
--
Kazunori Fujiwara
> From: Michael McNally
> PLEASE READ: An important security announcement from ISC
>
> ISC
William Thierry SAMEN wrote:
>
> My file zone:
Er this looks like a key file, not a zone file. The key has been generated
incorrectly: it has a file name where the zone name should be.
> ; This is a zone-signing key, keyid 12762, for *../etc/toto.com.*
> ; Created: 20120207101131 (Tue Feb 7 11:
Absolutely Tony that was a key file which has been generated by
dnssec-keygen command.
My zone file is so simple and its look like that i have checked it before
with the named-checkzone and all is good in my file zone.
I changed option -o by the option -o only and now i had this error:
dnssec-
William Thierry SAMEN wrote:
>
> dnssec-signzone: error: dns_master_load: ../etc/toto.com:12: toto.com: not at
> top of zone
> dnssec-signzone: fatal: failed loading zone from '../etc/toto.com': not at
> top of zone
This is because your zone uses an include directive to import the key
files, an
William: In my tests of DNSSEC, I have used 'auto-dnsssec maintain;' rather
than explicitly signing the zone with dnssec-signzone. I believe I recall that
you are using bind 9.8, so this should work for you as well. Here's something
you can try:
In your bind configuration use the following zone
On Feb 8 2012, Kazunori Fujiwara wrote:
Searching the title of the vulnerability with google results one PDF document.
http://www.google.co.jp/#q=Ghost+Domain+Names:+Revoked+Yet+Still+Resolvable+PDF
It shows details.
More directly, http://www.cs.indiana.edu/classes/b649-gupt/kangLiNDSS12.pdf
Thank you very much for your help i'm going to try it wright now.
2012/2/8 Spain, Dr. Jeffry A.
> William: In my tests of DNSSEC, I have used 'auto-dnsssec maintain;'
> rather than explicitly signing the zone with dnssec-signzone. I believe I
> recall that you are using bind 9.8, so this should
Chris Thompson wrote:
>
> More directly, http://www.cs.indiana.edu/classes/b649-gupt/kangLiNDSS12.pdf
>
> This is definitely worth reading, being an interesting new twist on a
> fairly old theme.
Paul Vixie was trying to do something about risks in this area a couple of
years ago: http://tools.ie
I have spend the afternoon trying to figure this out. The response I
get back from their nameserver looks fine to me, and dig +trace works
fine, but a regular dig returns a servfail. I have looked at the code
for invalid response, but I don't quite follow what is going on there,
and the comment 're
Microsoft's servers are broken. "aa" should be set but it isn't.
Mark
; <<>> DiG 9.7.3-P3 <<>> winqual.partners.extranet.microsoft.com
@dns10.one.microsoft.com +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24074
;; flags: qr ra; QUERY: 1, ANS
On 2/8/2012 10:32 PM, Matt Doughty wrote:
I have spend the afternoon trying to figure this out. The response I
get back from their nameserver looks fine to me, and dig +trace works
fine, but a regular dig returns a servfail. I have looked at the code
for invalid response, but I don't quite follow
I was thinking why RFC requires the values of MX and NS must be hostname
not IP.
Any glue? Thanks.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https:
In message <4f337229.1090...@staff.dnsbed.com>, Jeff Peng writes:
> I was thinking why RFC requires the values of MX and NS must be hostname
> not IP.
> Any glue? Thanks.
When you serve 10 zones do you want to update 1 address
record or 10 NS record on a address change?
On 09.02.12 15:13, Jeff Peng wrote:
I was thinking why RFC requires the values of MX and NS must be
hostname not IP.
because it IS the hostname, not an IP.
A points to IP(v4)
points to IP(v6)
NS, MX, PTR, CNAME... all others point to hostname.
otherwise, someone would need to decide what
δΊ 2012-2-9 15:27, Mark Andrews ει:
When you serve 10 zones do you want to update 1 address
record or 10 NS record on a address change?
When you serve 10 mail domains do you want to update 1
address record or 10 MX records on a address change?
Yup
17 matches
Mail list logo
