On 22/03/2016 16:44, Bob Harold wrote:
> I appreciate the announcement of the change ahead of time, but I don't feel
> like it is safe to update my root hints file based on an email, which could
> be spoofed. It's not that I don't trust you, but someone could spoof your
> email.
> So I am waiti
This is reminder that there is a scheduled change to the IPv6 addresses
for the
L-Root server, that will take effect on March 23, 2016.
The new IP addresses for the L.ROOT-SERVERS.NET will be:
199.7.83.42
2001:500:9f::42
Please remember to update your root “hints” files on your DNS
infrastruct
http://www.internic.net/domain/named.cache
John Bond
Lead DNS Engineer
ICANN
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBAgAGBQJW4rhbAAoJEItBgrEZay0nMjYQAMEK/PCTXh2BRB0op61N61/7
t8myqUuQhvLuKh/7i2K2DA/8Ud/ZZ4S+GEZqvSgq2tSz0EfcpQg4kmVWaQn
infrastructure operators to update their DNS resolvers
root "hints” file.
New hints files will be available at the following URLs once the change
has been formally executed on March 23, 2016:
* http://www.internic.net/domain/named.root
* http://www.internic.net/domain/named.cache
John Bond
Lea
On 7/28/11 9:43 AM, Stephane Bortzmeyer wrote:
> Did you try to obtain an independent confirmation from a reliable
> source? (I do not know this product, but I distrust private black
> boxes.) I recommend:
NeXpose is a good vulnerability auditor, it is a product by Rapid7 the
owners of metasploit.
On 5/4/11 10:22 AM, hugo hugoo wrote:
>
> So..no way to check that a zone is expired?
Hello Hugo,
I recently wrote a small script which mails me about any zones that is due to
expire within the next 24 hours. This works by using the last change time of
the file on disk and the SOA expiry time
On 4/18/11 2:17 PM, hostmas...@g-net.be wrote:
>
> and when I configure my zone like this in named.conf.local :
>
> zone "zone.be" {
> type master;
> file "/dnszones/db.zone.be.signed";
> auto-dnssec maintain;
> key-directory "/dnskeys/";
> sig-validity-in
On Sun, Jan 25, 2009 at 6:39 PM, Matus UHLAR - fantomas
wrote:
>> When i tried this host did not resolve
>> the cname. i.e a host 1.1.1.1 returned metis.local. it did not know
>> to resolve metis.local as bob
>
> the host 1.1.1.1 returned that 1.1.1.1.in-addr.arpa is a CNAME to
> metis.loc
On Sat, Jan 24, 2009 at 9:21 PM, Matus UHLAR - fantomas
wrote:
>
> if metis.local is a CNAME, the PTR shouldn't point to it.
> --
could you please explain this. When i tried this host did not resolve
the cname. i.e a host 1.1.1.1 returned metis.local. it did not know
to resolve metis.local as b
On Sat, Jan 24, 2009 at 4:06 AM, Barry Margolin wrote:
> Why don't you just use normal reverse DNS:
>
> zone for 1.1.1.in-addr.arpa
>
> 1 IN PTR metis.local.
> IN PTR bob-www-sol-l01.local.
I read there were problems having 2 PTR records for the same ip. I
know its in the RFC but thought MTA's
Hello All,
Sorry for the bad subject but i wasn't really sure how i could best
describe my circumstances. I would like to ask anyone out there if
something im proposing to implment is incorrect or just plain stupid.
Ok so the situation is that we have one set of developers who like to
call there
11 matches
Mail list logo
