On 02/28/2013 06:21 PM, Mark Andrews wrote:
In message <512fb319.7030...@htt-consult.com>, Robert Moskowitz writes:
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt.INDNSKEY257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWM
In message
, Mesut
GULNAZ writes:
>
> solved by deleting all setting here
> http://technet.microsoft.com/en-us/library/cc786695(v=3Dws.10).aspx
>
> thanks for all..
Which should not have impacted on search lists based on the documentation.
You should file a bug report with Microsoft.
Mark
In message <512fb319.7030...@htt-consult.com>, Robert Moskowitz writes:
> I MAY be doing something wrong, or my problem is elsewhere...
>
> In zone htt. I have the DNSKEY RR:
>
> htt.INDNSKEY257 3 7
> AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
> NyA4CVaaG4GMekSJM8dI0F
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
On 02/28/2013 02:42 PM, Robert Moskowitz wrote:
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt. IN DNSKEY 257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/H
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt.INDNSKEY257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5g
> 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
Doug wrote on 02/28/2013 12:31:21 PM:
> You probably want to have some discussions with OS vendors that embed
> BIND to familiarize yourself with how many people are using ESV versions
> from that channel.
Or even older versions.
FWIW, Ubuntu 8.04LTS uses bind 9.4.2. They backport critical f
solved by deleting all setting here
http://technet.microsoft.com/en-us/library/cc786695(v=ws.10).aspx
thanks for all..
2013/2/28 Kevin Darcy
> This is a combination of
> a) your client appending a search suffix *before* looking up the
> fully-qualified domain name _as_is_, and
> b) your local
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
On 02/28/2013 02:37 AM, Shane Kerr wrote:
Note though that as far as I can tell, few people actually use the ESV
software. Please let us know if the ESV policy works for you!
You probably want to have some discussions with OS vendors that embed
BIND to familiarize yourself with how many people
This is a combination of
a) your client appending a search suffix *before* looking up the
fully-qualified domain name _as_is_, and
b) your local nameserver, or something in your forwarding path (if you
have one), having a local definition of localdomain.com with a wildcard
entry in it
You cou
Shane Kerr wrote on 02/28/2013 05:37:26 AM:
> On Thursday, 2013-02-28 11:19:01 +1100,
> Mark Andrews wrote:
> >
>
> ISC has no specific plans to end BIND 9 development. As Mark correctly
> says:
Thanks for the clarification.
> > BIND 10 is still a way off being a replacement for BIND 9.
>
In message , Tony
Finch writes:
> Mesut GULNAZ wrote:
>
> > when i query bind for www.google.com from a PC from my network
> > bind response me with www.google.com.localdomain.com
> > with no result
>
> Sounds like you have a wildcard in your local domain and the
> resolver search path include
Mesut GULNAZ wrote:
> when i query bind for www.google.com from a PC from my network
> bind response me with www.google.com.localdomain.com
> with no result
Sounds like you have a wildcard in your local domain and the
resolver search path includes your local domain.
Tony.
--
f.anthony.n.finch
William,
On Thursday, 2013-02-28 11:19:01 +1100,
Mark Andrews wrote:
>
> In message
> ,
> wbr...@e1b.org writes:
> > Congrats to ISC and everyone that has worked on BIND 10!
> >
> > I am building new name servers and redesigning our infrastructure
> > with an eye towards streamlining, improvin
On 28.02.13 08:41, Abdul Khader wrote:
Is there a way to flush MX records from the cache of a caching DNS server ?
No. You only can flush whole cache (rndc flush) or flush records for given
domain (rndc flushname).
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning:
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 27.02.13 17:32, Marco C. Coelho wrote:
Mark Andrews was right.
This server was being hammered so hard that logging the rejects was
killing the performance.
adding:
logging {
category default { null; };
//category lame-servers { null; };
};
to named.conf fixed the performance issues.
You
when i query bind for www.google.com from a PC from my network
bind response me with www.google.com.localdomain.com
with no result
but when i query again with DOT at the end of the domain like www.google.com
*.* it respoense true.
what can i do to solve this?
--
Thanks..
Mesut GÜLNAZ
__
28 matches
Mail list logo
