Our experience has been they break, unexpectedly and in hard to troubleshoot
ways.
FQDN for the win!
Vernon Schryver wrote:
>
>With "search" lists in /etc/resolv.conf (and the Windows equivalent)
>or checking /etc/hosts (and the Windows equivalent) before DNS (while
>ignoring the DNS ubber all
> From: Robert Moskowitz
> could work plugged in or isolated. Really now I could force things to
> work as a subzone; or at least I think I am nearly to that point in the
> upgrades. But there are some human interaction reasons for a very short
> fqdn for a class of testing. It has to be typed
On 02/28/2013 01:31 PM, Vernon Schryver wrote:
From: Tony Finch
Another reason not to use made-up domain names: CAs are going to stop
issuing X.509 certificates for them. (It baffles me why they ever did so.)
http://ssl.entrust.net/blog/?p=1831
That's another reason to publish your own DANE re
On 02/28/2013 01:14 PM, Tony Finch wrote:
Robert Moskowitz wrote:
Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got
insecure response; parent indicates it should be secure
I think this suggests that one of the servers for htt doesn't have the
signed version.
Anothe
On 02/28/2013 12:57 PM, Vernon Schryver wrote:
From: Robert Moskowitz
Well one really shouldn't be creating one's own tlds.
As the instigator and a co-author of rfc 1918, I beg to differ.
Many people considered the notion in RFC 1918 harmful. See RFC 1627.
Um, I lived that debate.
RFC 15
> From: Tony Finch
> Another reason not to use made-up domain names: CAs are going to stop
> issuing X.509 certificates for them. (It baffles me why they ever did so.)
> http://ssl.entrust.net/blog/?p=1831
That's another reason to publish your own DANE records including
TLSA and SMIMEA.
Also c
Robert Moskowitz wrote:
> Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got
> insecure response; parent indicates it should be secure
I think this suggests that one of the servers for htt doesn't have the
signed version.
Another reason not to use made-up domain names:
On 02/28/2013 12:37 PM, Doug Barton wrote:
On 02/28/2013 09:34 AM, Robert Moskowitz wrote:
Only for my internal tld does the lookup fail.
Are you distributing the trust anchor for htt to all of the servers
that are doing validation?
No. Of course I did not think of that! I just ASSuMEd a n
> From: Robert Moskowitz
> > Well one really shouldn't be creating one's own tlds.
>
> As the instigator and a co-author of rfc 1918, I beg to differ.
Many people considered the notion in RFC 1918 harmful. See RFC 1627.
(My personal view was that standardizing the notion was better because
it w
On 02/28/2013 09:34 AM, Robert Moskowitz wrote:
Only for my internal tld does the lookup fail.
Are you distributing the trust anchor for htt to all of the servers that
are doing validation?
Doug
___
Please visit https://lists.isc.org/mailman/listi
Still not working even with htt. signed. See below. I guess what I
need for right now is to turn off DNSSEC checking of a branch in the
tree; in this case the tld htt.
On 02/27/2013 08:34 PM, Mark Andrews wrote:
In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:
For var
In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:
For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching server that 'forwards only' to my
internal serv
On 02/27/2013 08:34 PM, Mark Andrews wrote:
In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:
For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching s
In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:
> For various testing reasons, I have been running a tld here of htt. It
> has worked of old and continues to work on my new 9.8.2 Centos servers.
> Problem came up from a namecaching server that 'forwards only' to my
> in
For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching server that 'forwards only' to my
internal server. It cannot resolve any hosts in this tld and on the
server forwar
15 matches
Mail list logo
