On the original topic, it would be nice to have a dig option that
returned both A and with one command.
Since it does this, I tend to use 'host' (note that host -v gives the
same response detail as dig -t A ; dig -t ; and dig -t MX).
On the other remarks, inline.
On 14-Jun-17 21:09,
In message <5856c2c2-6049-2556-7f0a-7d391377c...@acm.org>, Timothe Litt writes:
>
> On the original topic, it would be nice to have a dig option that
> returned both A and with one command.
>
> Since it does this, I tend to use 'host' (note that host -v gives the
> same response detail as
In message <3ffd4a84-2b7c-78a1-0e35-e741c6d98...@gmail.com>, Sachin Garg writes:
>
> On the point of customers not getting IPv6 (last point below) please see
> this issue for android opened 5 (!) years ago:
>
> Support for DHCPv6 (RFC 3315)
> https://issuetracker.google.com/issues/36949085
>
>
In message <20170614132510.6ff832a5@ime1.iment.local>, Paul Kosinski writes:
> Has IPv4 faded away and I didn't notice? Unlike the well planned switch
> to Area Codes, IPv6 is not backward compatible.
It has started to fade away. If you have IPv6 at home, statistically,
most of your traffic
On the point of customers not getting IPv6 (last point below) please see
this issue for android opened 5 (!) years ago:
Support for DHCPv6 (RFC 3315)
https://issuetracker.google.com/issues/36949085
So, when a corp like Google also takes such a pathetic position, what
can one say about ISPs?
On
https://kb.isc.org/article/AA-00320/0/Why-cant-named-update-slave-zone-database-files-slave-journal-files-and-master-zones-from-journals-.html
In message <1497474665849-3948.p...@n4.nabble.com>, Latitude writes:
> Thanks for your reply Tony. Great references. I've got the ARM for 9.8.2
> handy
Has IPv4 faded away and I didn't notice? Unlike the well planned switch
to Area Codes, IPv6 is not backward compatible.
(The telcos would have gotten rather a lot of complaints if they said
every had to get a new telephone number, and also -- new telephones.)
On Wed, 14 Jun 2017 22:10:25 +1000
Due to customer requirements, I'm deploying BIND 9.8.2 on RHEL 6.8 and can
neither upgrade BIND to a newer version or upgrade to RHEL 7. I have
successfully configured a master and slave DNS server, DNSSEC, with
Transaction Signatures, and have performed a successful manual zone update,
Latitude wrote:
>
> I have read in Michael W. Lucas' DNSSEC Mastery book that BIND 9.9 and newer
> can automatically sign zones and refresh signatures (RRSIGs), but older
> versions cannot (p. 53).
That isn't entirely correct: BIND has had automatic signing since 9.7
Thanks for your reply Tony. Great references. I've got the ARM for 9.8.2
handy but thank you for sending the link to your article and pointing me out
to Section 4.9.3 Fully Automatic Signing. It's been helpful to confirm zone
RRSIGs can refresh automatically.
A zone that was signed with a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
http://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEAREKAAYFAlj6vdIACgkQL6j7milTFsHerACfQB+wrypAkmqxjX/4vw/PY5XG
On 2017-06-14 10:45:30 +, Marco Davids (SIDN) said:
Hi,
Not sure if this has been proposed before, but I am wondering:
Has ISC ever considered to change the default 'dig -t' option from A to ?
Or a -H option to do both A and queries in a kind of Happy Eyeballs mode?
(Yes, I
Hi,
Not sure if this has been proposed before, but I am wondering:
Has ISC ever considered to change the default 'dig -t' option from A to
?
--
Marco
signature.asc
Description: OpenPGP digital signature
___
Please visit
In message , "Marco Davids
(SIDN)" writes:
> Hi,
>
> Not sure if this has been proposed before, but I am wondering:
>
> Has ISC ever considered to change the default 'dig -t' option from A to
> ?
>
> --
> Marco
This would break too many scripts.
14 matches
Mail list logo