Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

2012-02-09 Thread Matt Doughty
I would have to back port right now, and I have a work around that will work until the we bump our fleet to a newer version. I was mostly concerned about whether it was something in our network causing the problem. Thanks for all the help guys, --Matt On Thu, Feb 9, 2012 at 4:42 PM, Spain, Dr. J

Re: State diagram for DNSsec key lifecycle

2012-02-09 Thread Mark Andrews
You don't submitt the initial DS until the KSK is active and any old state about the DNSKEY as clear caches. I recommend "activate" + "publish" at the same time. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

RE: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

2012-02-09 Thread Spain, Dr. Jeffry A.
> It's because a few load balancer vendors don't read freely available > specifications but instead appear to reverse engineer the protocol and get it > wrong. > BIND 9.7.0 fixed a long standing of accepting glue promoted to answer by > parent nameservers. Once we did that there was no need to

RE: State diagram for DNSsec key lifecycle

2012-02-09 Thread Spain, Dr. Jeffry A.
> Please comment on this state diagram: > https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf For greater clarity, I suggest that for the state transitions (captions on the arrows), you refer specifically to the four metadata timestamps that are present in the

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

2012-02-09 Thread Mark Andrews
In message , Matt Doughty writes: > It seems like multiple things are wrong, but I'm still trying to > understand what part of the breakage is causing Bind to throw out the > response with the formerr 'invalid response'. Is this broken for > everyone using bind 9.7 or later? I can just forward

State diagram for DNSsec key lifecycle

2012-02-09 Thread Axel Rau
While writing a script for key maintenance of 'auto-dnssec maintained' zones, I try to understand the required actions and states of the keys. Please comment on this state diagram: https://www.chaos1.de/svn-public/repos/network-tools/DNSsec/trunk/dnssec_key_states.pdf Actions of the script

Re: DNSSEC and CVE-2012-1033 (Ghost domain names)

2012-02-09 Thread Gilles Massen
On 9/2/12 21:38 , Casey Deccio wrote: > > Is it because the resolver, even if sticky, re-queries the parent when > the negative TTL of the (missing) DS records ends? And chokes when it > receives back a NXDOMAIN? > > > Actually, what I have observed in my limited testing is that the

Re: DNSSEC and CVE-2012-1033 (Ghost domain names)

2012-02-09 Thread Casey Deccio
On Thu, Feb 9, 2012 at 1:26 AM, Stephane Bortzmeyer wrote: > Unless you make DNSSEC mandatory, how will > you solve the ghost domain problem with DNSSEC? If the resolver is > sticky (will not go to the parent to ask the NS RRset), it won't check > the NSEC at the parent either... > > Actually, it

Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

2012-02-09 Thread Matt Doughty
It seems like multiple things are wrong, but I'm still trying to understand what part of the breakage is causing Bind to throw out the response with the formerr 'invalid response'. Is this broken for everyone using bind 9.7 or later? I can just forward this zone to HonestDNS, which happily serves

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread michoski
On 2/9/12 9:43 AM, "Lyle Giese" wrote: > This is just my opinion, but this is not a bug. It's the side effect of > a desirable feature called caching. > > Yea, we can brainstorm how to mitigate the effect, but in order to > mitigate a problem, we have to know that there is a problem(revoked or >

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Lyle Giese
On 02/09/12 09:56, Matus UHLAR - fantomas wrote: > Questions: > (1) It looks to me like if the ghost name is in our >DNS RPZ zone, then that 'fixes' the problem for >that name. Is this correct? Ghost domain could be redelegated to a new owner and become absolutely legal. On 09.02.12

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Matus UHLAR - fantomas
> Questions: > (1) It looks to me like if the ghost name is in our >DNS RPZ zone, then that 'fixes' the problem for >that name. Is this correct? Ghost domain could be redelegated to a new owner and become absolutely legal. On 09.02.12 07:36, John Hascall wrote: Caveat Emptor -- if

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Chris Thompson
On Feb 9 2012, Peter Andreev wrote: 2012/2/9 John Hascall [...snip...] (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts (new different ghost names could, of course, be created).Is this corr

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Gilles Massen
The easier way to mitigation is to enable dnssec validation on the resolver (which is a good thing anyway). From my tests this changes the behaviour of bind in so far that it respects the TTL of the NS set rather strictly, and returns to the parent on expiry. Looks like the most efficient long-te

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread John Hascall
> > Questions: > > (1) It looks to me like if the ghost name is in our > >DNS RPZ zone, then that 'fixes' the problem for > >that name. Is this correct? > > Ghost domain could be redelegated to a new owner and become absolutely > legal. Caveat Emptor -- if you buy a former TDSS (or

Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Peter Andreev
2012/2/9 John Hascall > > > Questions: > > (1) It looks to me like if the ghost name is in our >DNS RPZ zone, then that 'fixes' the problem for >that name. Is this correct? > Ghost domain could be redelegated to a new owner and become absolutely legal. > > (2) It also looks like resta

CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread John Hascall
Questions: (1) It looks to me like if the ghost name is in our DNS RPZ zone, then that 'fixes' the problem for that name. Is this correct? (2) It also looks like restarting bind flushes the cache and that prevents the repopulation of the local cache with names which are ghosts

DNSSEC and CVE-2012-1033 (Ghost domain names)

2012-02-09 Thread Stephane Bortzmeyer
In , ISC writes: > ISC continues to recommend that organizations with security needs > who are reliant on the Domain Name System proceed with adoption of > DNSSEC; DNSSEC is the best known method of mitigating this issue. But ISC provid