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

[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. Jeffry A.
 wrote:
>> 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 accept none "aa" 
>> answers from servers that have been listed as being authoritative for the 
>> zone.  This allowed the resolver to ignore broken authoritative servers.
>
>> This got relaxed in later release of BIND 9.7.
>
> It's fairly easy for me to deploy a VM and build a particular version of 
> bind. Below is your query run on 9.7.0-P1 and 9.7.4-P1. It fails on the 
> former and succeeds on the latter, as suggested by Mark Andrews above. Are 
> you in a position to upgrade bind? Jeff.
>
>
> ; <<>> DiG 9.7.0-P1 <<>> @localhost winqual.partners.extranet.microsoft.com.
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28201
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;winqual.partners.extranet.microsoft.com. IN A
>
> ;; Query time: 1744 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Feb  9 19:36:51 2012
> ;; MSG SIZE  rcvd: 57
>
>
> ; <<>> DiG 9.7.4-P1 <<>> @localhost winqual.partners.extranet.microsoft.com.
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47557
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;winqual.partners.extranet.microsoft.com. IN A
>
> ;; ANSWER SECTION:
> winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31
>
> ;; AUTHORITY SECTION:
> partners.extranet.microsoft.com. 3600 IN NS     dns11.one.microsoft.com.
> partners.extranet.microsoft.com. 3600 IN NS     dns12.one.microsoft.com.
> partners.extranet.microsoft.com. 3600 IN NS     dns10.one.microsoft.com.
> partners.extranet.microsoft.com. 3600 IN NS     dns13.one.microsoft.com.
>
> ;; Query time: 668 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Feb  9 19:15:58 2012
> ;; MSG SIZE  rcvd: 157
>



-- 
--Matt
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: State diagram for DNSsec key lifecycle

[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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 accept none "aa" 
> answers from servers that have been listed as being authoritative for the 
> zone.  This allowed the resolver to ignore broken authoritative servers.

> This got relaxed in later release of BIND 9.7.

It's fairly easy for me to deploy a VM and build a particular version of bind. 
Below is your query run on 9.7.0-P1 and 9.7.4-P1. It fails on the former and 
succeeds on the latter, as suggested by Mark Andrews above. Are you in a 
position to upgrade bind? Jeff.


; <<>> DiG 9.7.0-P1 <<>> @localhost winqual.partners.extranet.microsoft.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28201
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;winqual.partners.extranet.microsoft.com. IN A

;; Query time: 1744 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  9 19:36:51 2012
;; MSG SIZE  rcvd: 57


; <<>> DiG 9.7.4-P1 <<>> @localhost winqual.partners.extranet.microsoft.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47557
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0

;; QUESTION SECTION:
;winqual.partners.extranet.microsoft.com. IN A

;; ANSWER SECTION:
winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31

;; AUTHORITY SECTION:
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.

;; Query time: 668 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  9 19:15:58 2012
;; MSG SIZE  rcvd: 157

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: State diagram for DNSsec key lifecycle

[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 keys: Publish, Activate, Inactive, and Delete, since these 
govern what bind does with the keys.

I think it would help also to add some information about how you will set the 
values for these timestamps when the keys are generated with dnssec-keygen.

You don't address the issue of key revocation, but perhaps that should wait for 
later.

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 this zone to
> HonestDNS, which happily serves up the data, and lodge a complaint
> with Microsoft to fix their servers, but I want to make sure there
> isn't something wrong somewhere in my network that is causing this
> problem.
> 
> thanks,
> 
> --Matt

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 accept none "aa" answers from servers that have been listed as
being authoritative for the zone.  This allowed the resolver to
ignore broken authoritative servers.

This got relaxed in later release of BIND 9.7.

> On Wed, Feb 8, 2012 at 8:05 PM, David Miller  wrote:
> > On 2/8/2012 10:32 PM, Matt Doughty wrote:
> >>
> >> I have spend the afternoon trying to figure this out. The response I
> >> get back from their nameserver looks fine to me, and dig +trace works
> >> fine, but a regular dig returns a servfail. I have looked at the code
> >> for invalid response, but I don't quite follow what is going on there,
> >> and the comment 'responder is insane' leaves something to be desired.
> >> Any help would be appreciated here. I have included the dig +trace
> >> output below:
> >>
> >> dig +trace winqual.partners.extranet.microsoft.com.
> >>
> >> ;<<>>  DiG 9.7.0-P1<<>>  +trace 
> winqual.partners.extranet.microsoft.com.
> >> ;; global options: +cmd
> >> .                       518004  IN      NS     
> >>  j.root-servers.net.
> >> .                       518004  IN      NS     
> >>  e.root-servers.net.
> >> .                       518004  IN      NS     
> >>  l.root-servers.net.
> >> .                       518004  IN      NS     
> >>  c.root-servers.net.
> >> .                       518004  IN      NS     
> >>  m.root-servers.net.
> >> .                       518004  IN      NS     
> >>  d.root-servers.net.
> >> .                       518004  IN      NS     
> >>  b.root-servers.net.
> >> .                       518004  IN      NS     
> >>  h.root-servers.net.
> >> .                       518004  IN      NS     
> >>  k.root-servers.net.
> >> .                       518004  IN      NS     
> >>  a.root-servers.net.
> >> .                       518004  IN      NS     
> >>  g.root-servers.net.
> >> .                       518004  IN      NS     
> >>  i.root-servers.net.
> >> .                       518004  IN      NS     
> >>  f.root-servers.net.
> >> ;; Received 228 bytes from 172.16.255.1#53(172.16.255.1) in 1 ms
> >>
> >> com.                    172800  IN      NS     
> >>  h.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  f.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  m.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  g.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  l.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  c.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  d.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  a.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  b.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  i.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  j.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  e.gtld-servers.net.
> >> com.                    172800  IN      NS     
> >>  k.gtld-servers.net.
> >> ;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 18 ms
> >>
> >> microsoft.com.          172800  IN      NS      ns3.msft.net.
> >> microsoft.com.          172800  IN      NS      ns1.msft.net.
> >> microsoft.com.          172800  IN      NS      ns5.msft.net.
> >> microsoft.com.          172800  IN      NS      ns2.msft.net.
> >> microsoft.com.          172800  IN      NS      ns4.msft.net.
> >> ;; Received 235 bytes from 192.43.172.30#53(i.gtld-servers.net) in 67 
> ms
> >>
> >> partners.extranet.microsoft.com. 3600 IN 

State diagram for DNSsec key lifecycle

[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 are in red color. mgmt dir is the per zone directory 
where named finds the keys.

Axel
---
PGP-Key:29E99DD6  ☀ +49 151 2300 9283  ☀ computing @ chaos claudius

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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
> resolver re-queries the parent after the TTL of the NS RRset in the
> parent, not the negative TTL of the parent.  Upon receiving a NXDOMAIN
> response, it passes that along to the client.

This is what I saw as well, but if the NS rrset is queried explicitly
then the authoritative data from the child (with its TTL) overrides the
cache with the parent's TTL, just as described in the 'vulnerability'.
However, with dnssec-validation enabled, this happens only once - so if
that TTL expires the parent is asked again.

So the maximal exposure to a removed delegation with a validating bind
resolver would be TTL(NS)+TTL(RR), under very favorable conditions. This
could be a long time, but it's not forever.

Best,
Gilles
.lu


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 should, in the spirit of DNSSEC.  With a trusted anchor,
DNSSEC provides a chain of trust--whether it terminates in an insecure
delegation (i.e., with NSEC or NSEC3 RRs) or continues all the way to the
RRset begin sought.  Once any records in that chain expire from cache, the
chain needs to be refreshed, or there is no way to tell if the name is
expected to have a secure validation path or not.  While I don't know if
the "how" is specified in RFCs, in my recent observation both bind and
unbound do exhibit that behavior, though with slight differences.


> 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 resolver
re-queries the parent after the TTL of the NS RRset in the parent, not the
negative TTL of the parent.  Upon receiving a NXDOMAIN response, it passes
that along to the client.

Casey
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 up the data, and lodge a complaint
with Microsoft to fix their servers, but I want to make sure there
isn't something wrong somewhere in my network that is causing this
problem.

thanks,

--Matt

On Wed, Feb 8, 2012 at 8:05 PM, David Miller  wrote:
> On 2/8/2012 10:32 PM, Matt Doughty wrote:
>>
>> I have spend the afternoon trying to figure this out. The response I
>> get back from their nameserver looks fine to me, and dig +trace works
>> fine, but a regular dig returns a servfail. I have looked at the code
>> for invalid response, but I don't quite follow what is going on there,
>> and the comment 'responder is insane' leaves something to be desired.
>> Any help would be appreciated here. I have included the dig +trace
>> output below:
>>
>> dig +trace winqual.partners.extranet.microsoft.com.
>>
>> ;<<>>  DiG 9.7.0-P1<<>>  +trace winqual.partners.extranet.microsoft.com.
>> ;; global options: +cmd
>> .                       518004  IN      NS      j.root-servers.net.
>> .                       518004  IN      NS      e.root-servers.net.
>> .                       518004  IN      NS      l.root-servers.net.
>> .                       518004  IN      NS      c.root-servers.net.
>> .                       518004  IN      NS      m.root-servers.net.
>> .                       518004  IN      NS      d.root-servers.net.
>> .                       518004  IN      NS      b.root-servers.net.
>> .                       518004  IN      NS      h.root-servers.net.
>> .                       518004  IN      NS      k.root-servers.net.
>> .                       518004  IN      NS      a.root-servers.net.
>> .                       518004  IN      NS      g.root-servers.net.
>> .                       518004  IN      NS      i.root-servers.net.
>> .                       518004  IN      NS      f.root-servers.net.
>> ;; Received 228 bytes from 172.16.255.1#53(172.16.255.1) in 1 ms
>>
>> com.                    172800  IN      NS      h.gtld-servers.net.
>> com.                    172800  IN      NS      f.gtld-servers.net.
>> com.                    172800  IN      NS      m.gtld-servers.net.
>> com.                    172800  IN      NS      g.gtld-servers.net.
>> com.                    172800  IN      NS      l.gtld-servers.net.
>> com.                    172800  IN      NS      c.gtld-servers.net.
>> com.                    172800  IN      NS      d.gtld-servers.net.
>> com.                    172800  IN      NS      a.gtld-servers.net.
>> com.                    172800  IN      NS      b.gtld-servers.net.
>> com.                    172800  IN      NS      i.gtld-servers.net.
>> com.                    172800  IN      NS      j.gtld-servers.net.
>> com.                    172800  IN      NS      e.gtld-servers.net.
>> com.                    172800  IN      NS      k.gtld-servers.net.
>> ;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 18 ms
>>
>> microsoft.com.          172800  IN      NS      ns3.msft.net.
>> microsoft.com.          172800  IN      NS      ns1.msft.net.
>> microsoft.com.          172800  IN      NS      ns5.msft.net.
>> microsoft.com.          172800  IN      NS      ns2.msft.net.
>> microsoft.com.          172800  IN      NS      ns4.msft.net.
>> ;; Received 235 bytes from 192.43.172.30#53(i.gtld-servers.net) in 67 ms
>>
>> partners.extranet.microsoft.com. 3600 IN NS     dns10.one.microsoft.com.
>> partners.extranet.microsoft.com. 3600 IN NS     dns13.one.microsoft.com.
>> partners.extranet.microsoft.com. 3600 IN NS     dns11.one.microsoft.com.
>> partners.extranet.microsoft.com. 3600 IN NS     dns12.one.microsoft.com.
>> ;; Received 236 bytes from 64.4.59.173#53(ns2.msft.net) in 3 ms
>>
>> winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31
>> ;; Received 112 bytes from 131.107.125.65#53(dns10.one.microsoft.com) in
>> 23 ms
>>
>
> If I just dig at their servers for NS, I get a trunc and retry over TCP that
> times out.
>
> If I signal a bufsize, I get back a 777 byte response with NS that don't
> match the parent and an additional full of private 10/8 addresses
>
> # dig +norecurse +bufsize=1024 ns partners.extranet.microsoft.com
> @dns10.one.microsoft.com.
>
> ; <<>> DiG 9.8.1 <<>> +norecurse +bufsize=1024 ns
> partners.extranet.microsoft.com @dns10.one.microsoft.com.
>
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10678
> ;; flags: qr ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 17
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4000
> ;; QUESTION SECTION:
> ;partners.extranet.microsoft.com. IN    NS
>
> ;; ANSWER SECTION:
> partners.extranet.microsoft.com. 1076 IN NS
> tk5-ptnr-dc-02.partners.extran

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

[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
> bad domain).
> 
> 1) How would we(as dns server operators) know when a domain name is
> revoked? (Gee sounds like what the US government wants to do and it
> seems the community does not like that idea and I agree it's a bad idea
> to put the US DHS in charge of that list.)

+1 on less government (note: that doesn't mean lack of regulation, but it
should be community driven IMCO).

It really seems we need a "revoked domains" feed that could be used with RPZ
to implement the desired local policy (or not, choice rocks).  Obviously
this would need to be hosted somewhere like other DNSBLs, but would also
need a well defined mechanism (simple web services API?)  for registrars to
submit data...and then, of course, there's the issue of participation.

That said, this isn't a threat to the DNS servers themselves...  the main
concern is that someone could maintain a revoked domain and possibly
redirect folks there.  Controlling access to "bad" domains, revoked or not,
may be better accomplished by having local protection (think web proxy/AV
scanning with 0-day signatures) that reduces the impact "rogue" domains
could have on your organization.

-- 
Work is the curse of the drinking classes.
-- Mike Romanoff

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 07:36, John Hascall wrote:

  Caveat Emptor -- if you buy a former TDSS (or someother evil) domain,
  that's just too bad.


unfortunately, RPZ or DNSSEC - solving this problem depends on while 
world using them, so with this flaw in DNS protocol we're screwed 
still. When you buy a domain, just check if it's blacklisted anywhere 
if you want to avoid this



> (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 correct?



AFAIK 'rndc flush' will do the same.


Thanks - we're doing a nightly restart for other reasons.


what?
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 
bad domain).


1) How would we(as dns server operators) know when a domain name is 
revoked? (Gee sounds like what the US government wants to do and it 
seems the community does not like that idea and I agree it's a bad idea 
to put the US DHS in charge of that list.)


2) Restart or flush our DNS cache frequently?  Let's assume the A record 
TTL is 24 hrs.  And if we decide to flush the cache once a day?  That 
leaves a whole bunch of time that we are open to this and not much 
remaining time for the record in cache.  I fail to see the benefit 
here.  The idea to flush just the 'bad' domain fails due to #1, IMHO.


3) Maybe I don't understand DNS cache and it's relationship with DNSSEC 
yet.  But if my server caches a good answer (verified via DNSSEC), why 
would my server recheck the DNSSEC records until the TTL has elapsed?  
My thinking(and I could be quite wrong here) is that my server will 
cache a good verified answer and DNSSEC does not seem to help here.  
Please let me know where I am wrong here if I am.


Lyle Giese
LCR Computer Services, Inc.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 you buy a former TDSS (or someother evil) domain,
  that's just too bad.


unfortunately, RPZ or DNSSEC - solving this problem depends on while 
world using them, so with this flaw in DNS protocol we're screwed 
still. 
When you buy a domain, just check if it's blacklisted anywhere if you 
want to avoid this



> (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 correct?



AFAIK 'rndc flush' will do the same.


Thanks - we're doing a nightly restart for other reasons.


what?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states. 
___

Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 correct?



AFAIK 'rndc flush' will do the same.


If you know the domain name in question, "rndc flushname ghost.example"
should be enough. (BIND 9.9 has "rndc flushtree" as well, but I think
clobbering the cached NS records for the ghost domain should be enough.)

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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-term fix to me...

Best,
Gilles

-- 
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 someother evil) domain,
   that's just too bad.


> > (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 correct?

> AFAIK 'rndc flush' will do the same.

Thanks - we're doing a nightly restart for other reasons.


John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 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 correct?
>

AFAIK 'rndc flush' will do the same.

>
> Thanks,
> John
>
>
> ---
> John Hascall, j...@iastate.edu
> Team Lead, NIADS (Network Infrastructure, Authentication & Directory
> Services)
> IT Services, The Iowa State University of Science and Technology
>
> > 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 provides no details about *how* exactly DNSSEC will solve the
> > problem. I'm puzzled. In the ghost domain names attack, the child zone
> > is controlled by the bad guy, who wants the domain to stick. So, he
> > will certainly not sign it. 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...
> >
> > 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?
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe
>  from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
--
AP
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

CVE-2012-1033 (Ghost domain names) mitigation

[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 (new different ghost names
could, of course, be created).Is this correct?

Thanks,
John

---
John Hascall, j...@iastate.edu
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)
IT Services, The Iowa State University of Science and Technology

> 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 provides no details about *how* exactly DNSSEC will solve the
> problem. I'm puzzled. In the ghost domain names attack, the child zone
> is controlled by the bad guy, who wants the domain to stick. So, he
> will certainly not sign it. 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...
> 
> 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?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
 from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[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 provides no details about *how* exactly DNSSEC will solve the
problem. I'm puzzled. In the ghost domain names attack, the child zone
is controlled by the bad guy, who wants the domain to stick. So, he
will certainly not sign it. 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...

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?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users