DNS software used by cloudflare

[pangj]

Hello,

do you know what dns software is used by cloudflare?
and how  they defend the DDoS against DNS?

thanks.
___
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: DNS software used by cloudflare

[Stephane Bortzmeyer]

On Tue, Sep 18, 2012 at 08:31:13PM +0800,
 pangj  wrote 
 a message of 12 lines which said:

> do you know what dns software is used by cloudflare?

I don't know.

> and how  they defend the DDoS against DNS?

http://blog.cloudflare.com/65gbps-ddos-no-problem
___
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

question about how a particular dig works ...

[M. Meadows]

dig www.careerone.com.au +short @8.8.8.8
www.careerone.com.au.edgesuite.net.
a903.g.akamai.net.
208.44.23.99
208.44.23.121

Why does the above dig work when 

dig careerone.com.au +nssearch @8.8.8.8
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server usw1.akam.net in 106 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server usw4.akam.net in 136 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server usc4.akam.net in 124 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server usc1.akam.net in 40 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server usw5.akam.net in 190 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server ns1-24.akam.net in 171 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server asia1.akam.net in 161 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 86400 1200 
from server ns1-50.akam.net in 161 ms.

shows 8 auth nameservers for careerone.com.au

and if you use 

dig www.careerone.com.au +short @ 

you get no answer.

How does that work? Where does the 8.8.8.8 google public dns server get its 
answer from?

Thanks.
Marty Meadows
Indianapolis, In.


  ___
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: question about how a particular dig works ...

[Niall O'Reilly]

On 18 Sep 2012, at 14:45, M. Meadows wrote:

> dig www.careerone.com.au +short @8.8.8.8
> www.careerone.com.au.edgesuite.net.
> a903.g.akamai.net.
> 208.44.23.99
> 208.44.23.121
> 
> Why does the above dig work when 

If you try 

dig +trace www.careerone.com.au

you'll find that the www... subdomain is delegated to a different
set of name servers.

Besides, there's a CNAME at the apex ...

/Niall

___
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: question about how a particular dig works ...

[M. Meadows]

Very helpful. Thank you. I was not expecting a subdomain by that name.

And as you point out it has a cname at the apex ... which I thought was not 
allowed.

Isn't it true that a cname record can't co-exist with any other record in a 
zone file? 

So if the soa record in the zone file is for www.careerone.com.au ... how does 
the cname record get defined and loaded successfully?





> Subject: Re: question about how a particular dig works ...
> From: niall.orei...@ucd.ie
> Date: Tue, 18 Sep 2012 15:22:40 +0100
> CC: bind-users@lists.isc.org
> To: sun-g...@live.com
> 
> 
> On 18 Sep 2012, at 14:45, M. Meadows wrote:
> 
> > dig www.careerone.com.au +short @8.8.8.8
> > www.careerone.com.au.edgesuite.net.
> > a903.g.akamai.net.
> > 208.44.23.99
> > 208.44.23.121
> > 
> > Why does the above dig work when 
> 
>   If you try 
> 
> dig +trace www.careerone.com.au
> 
>   you'll find that the www... subdomain is delegated to a different
>   set of name servers.
> 
>   Besides, there's a CNAME at the apex ...
> 
>   /Niall
> 
  ___
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: question about how a particular dig works ...

[/dev/rob0]

On Tue, Sep 18, 2012 at 10:43:47AM -0400, M. Meadows wrote:
> And as you point out it has a cname at the apex ... which I thought 
> was not allowed.

named will not accept it, and indeed, it is a violation of DNS 
standards. Other DNS implementations might allow it, however.

> Isn't it true that a cname record can't co-exist with any other 
> record in a zone file?

Sort of. A CNAME record in a signed zone will have its RRSIG and 
NSEC or NSEC3 of the same name. Otherwise, no other RR types can 
share the same name.

And a minor, but increasingly significant bit of pedantry: let's 
discuss zone *data* not zone *files.* Zone data can be in a journal 
or DLZ database, for example. As DNSSEC gains momentum, it is 
possible that manual editing of zone files will be replaced by 
nsupdate(8) and dynamic zones.

> So if the soa record in the zone file is for www.careerone.com.au 
> ... how does the cname record get defined and loaded successfully?

I'd guess this is served by something other than BIND named.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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

cname and soa record in the same zone file -- problem?

[M. Meadows]

Why / how does this work?

dig -t any www.careerone.com.au @ns2.tmpw.net.

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5_8.2 <<>> -t any www.careerone.com.au 
@ns2.tmpw.net.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15513
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3

;; QUESTION SECTION:
;www.careerone.com.au.  IN  ANY

;; ANSWER SECTION:
www.careerone.com.au.   2560IN  SOA ns1.tmpw.net. 
hostmaster.tmpw.net. 1347892090 16384 2048 1048576 2560
www.careerone.com.au.   14400   IN  NS  ns1.tmpw.net.
www.careerone.com.au.   14400   IN  NS  ns2.tmpw.net.
www.careerone.com.au.   14400   IN  NS  ns3.tmpw.net.
www.careerone.com.au.   600 IN  CNAME   
www.careerone.com.au.edgesuite.net.

;; ADDITIONAL SECTION:
ns1.tmpw.net.   3600IN  A   208.71.198.33
ns2.tmpw.net.   3600IN  A   63.121.30.233
ns3.tmpw.net.   3600IN  A   208.71.198.34

;; Query time: 81 msec
;; SERVER: 63.121.30.233#53(63.121.30.233)
;; WHEN: Tue Sep 18 08:48:30 2012
;; MSG SIZE  rcvd: 240


I thought a cname record can't coexist with any other records in a zone file. 
How does this even get loaded this way? What results should the owners of this 
domain expect? I assume they'll be inconsistent and problematic. Right?

Thanks!




  ___
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

Dig from workstation to answer?

[Lightner, Jeff]

I know that dig +trace can be used to see the path of name resolution starting 
from root server down to final answer.

What I’m wondering is if there is some set of options that would go from 
workstation to final answer?   That is to say only go to the root server if 
that is where the DNS topology internally sends me.

For example from my workstation if I search an internal domain we use I know 
which internal DNS server it goes to ask the question.   That DNS server in 
turn may refer to a separate internal DNS server which is authoritative for the 
domain or has the record cached.   A dig +trace is useless because the root 
servers know nothing about the domain.   I’ve found various things that give me 
parts of the information but wonder if there isn’t something that would do 
something like trace so I can see each DNS server that was referred to in such 
lookups.









Athena®, Created for the Cause™

Making a Difference in the Fight Against Breast Cancer





How and Why I Should Support Bottled Water!
Do not relinquish your right to choose bottled water as a healthy alternative 
to beverages that contain sugar, calories, etc. Your support of bottled water 
will make a difference! Your signatures count! Go to 
http://www.bottledwatermatters.org/luv-bottledwater-iframe/dswaters and sign a 
petition to support your right to always choose bottled water. Help fight 
federal and state issues, such as bottle deposits (or taxes) and organizations 
that want to ban the sale of bottled water. Support community curbside 
recycling programs. Support bottled water as a healthy way to maintain proper 
hydration. Our goal is 50,000 signatures. Share this petition with your friends 
and family today!



-
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--


___
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: question about how a particular dig works ...

[Kevin Darcy]

On 9/18/2012 9:45 AM, M. Meadows wrote:


dig www.careerone.com.au +short @8.8.8.8
www.careerone.com.au.edgesuite.net.
a903.g.akamai.net.
208.44.23.99
208.44.23.121

Why does the above dig work when

dig careerone.com.au +nssearch @8.8.8.8
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server usw1.akam.net in 106 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server usw4.akam.net in 136 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server usc4.akam.net in 124 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server usc1.akam.net in 40 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server usw5.akam.net in 190 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server ns1-24.akam.net in 171 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server asia1.akam.net in 161 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200 
86400 1200 from server ns1-50.akam.net in 161 ms.


shows 8 auth nameservers for careerone.com.au

and if you use

dig www.careerone.com.au +short @

you get no answer.

How does that work? Where does the 8.8.8.8 google public dns server 
get its answer from?


www.careerone.com.au is an alias (through chained aliasing) ultimately 
to a903.g.akamai.net. To get an authoritative answer for 
a903g.akamai.net you'd need to ask one of the g.akamai.net nameservers. 
Which is presumably what Google's public resolver did to get the answers 
it returned to your query.


- Kevin
___
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: Dig from workstation to answer?

[Tony Finch]

Lightner, Jeff  wrote:
>
> For example from my workstation if I search an internal domain we use I
> know which internal DNS server it goes to ask the question.   That DNS
> server in turn may refer to a separate internal DNS server which is
> authoritative for the domain or has the record cached.   A dig +trace is
> useless because the root servers know nothing about the domain.   I’ve
> found various things that give me parts of the information but wonder if
> there isn’t something that would do something like trace so I can see
> each DNS server that was referred to in such lookups.

You can trace upwards. To find the zone within which a name lives, ask for
the SOA. You'll probably bet a NOERROR / NODATA response with the SOA in
the authority section, for example, (1)

You can then ask for the NS records at that name to find where the name is
hosted. (2)

You can work up the namespace by trimming off a label and repeating the
process. (3) (4)

Given the parent name servers you can then check the delegation NS RRset
for the child. (5)

However, for private zones, it is possible that the NS records do not tell
the truth - the hostmaster may be relying on static configuration of all
the servers instead.


*** (1)

; <<>> DiG 9.9.2-vjs197.15rc1 <<>> soa hermes.cam.ac.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14961
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hermes.cam.ac.uk.  IN  SOA

;; AUTHORITY SECTION:
cam.ac.uk.  14400   IN  SOA authdns0.csx.cam.ac.uk. 
hostmaster.ucs.cam.ac.uk. 1347969556 14400 3600 604800 14400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 18 16:28:46 2012
;; MSG SIZE  rcvd: 109


*** (2)

; <<>> DiG 9.9.2-vjs197.15rc1 <<>> ns cam.ac.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28269
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cam.ac.uk. IN  NS

;; ANSWER SECTION:
cam.ac.uk.  86400   IN  NS  dns1.cl.cam.ac.uk.
cam.ac.uk.  86400   IN  NS  authdns0.csx.cam.ac.uk.
cam.ac.uk.  86400   IN  NS  ns2.ic.ac.uk.
cam.ac.uk.  86400   IN  NS  bitsy.mit.edu.
cam.ac.uk.  86400   IN  NS  dns0.eng.cam.ac.uk.
cam.ac.uk.  86400   IN  NS  dns0.cl.cam.ac.uk.
cam.ac.uk.  86400   IN  NS  authdns1.csx.cam.ac.uk.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 18 16:31:41 2012
;; MSG SIZE  rcvd: 200


*** (3)

; <<>> DiG 9.9.2-vjs197.15rc1 <<>> soa ac.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32406
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ac.uk. IN  SOA

;; ANSWER SECTION:
ac.uk.  86400   IN  SOA ns0.ja.net. operations.ja.net. 
2012091860 28800 7200 360 14400

;; Query time: 13 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 18 16:32:00 2012
;; MSG SIZE  rcvd: 91


*** (4)

; <<>> DiG 9.9.2-vjs197.15rc1 <<>> ns ac.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41140
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ac.uk. IN  NS

;; ANSWER SECTION:
ac.uk.  7474IN  NS  ns2.ja.net.
ac.uk.  7474IN  NS  ns4.ja.net.
ac.uk.  7474IN  NS  auth03.ns.uu.net.
ac.uk.  7474IN  NS  ws-fra1.win-ip.dfn.de.
ac.uk.  7474IN  NS  ns3.ja.net.
ac.uk.  7474IN  NS  ns0.ja.net.
ac.uk.  7474IN  NS  ns1.surfnet.nl.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 18 16:32:16 2012
;; MSG SIZE  rcvd: 202


*** (5)

; <<>> DiG 9.9.2-vjs197.15rc1 <<>> ns cam.ac.uk @ns0.ja.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48627
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 7, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cam.ac.uk. IN  NS

;; AUTHORITY SECTION:
cam.ac.uk.  86400   IN  NS  dns0.eng.cam.ac.uk.
cam.ac.uk.  86400   IN  NS  authdns1.csx.cam.ac.uk.
cam.ac.uk.  86400   IN  NS  ns2.ic.ac.uk.
cam.ac.uk.

RE: question about how a particular dig works ...

[M. Meadows]

Thanks Kevin. I understand how the chained alias works. Sorry, I didn't explain 
my question very well.

I can see that the 8.8.8.8 google public dns server gets an answer.

I know that this domain has a cname coexisting with an SOA record and NS 
records ... both of which I have read are a bad thing. And I've seen the other 
reply that indicates that this combination of records in a zone file wouldn't 
even load in BIND ... so it's done with some other more forgiving DNS app. 

What I also see (but failed to explain) is that we have a local nameserver that 
can't find an answer to the dig www.careerone.com.au query. Gets no record 
back. Our local nameserver is an AD server that just throws up its imaginary 
hands in despair. So is this what we should expect from this problematic DNS 
setup in the www.careerone.com.au zone file? Erratic or somewhat erratic 
results? Just curious why google and some other public facing dns servers get 
an answer when our own local nameserver can't figure it out.



Date: Tue, 18 Sep 2012 11:18:58 -0400
From: k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: question about how a particular dig works ...


  

  
  
On 9/18/2012 9:45 AM, M. Meadows wrote:



  
  


dig www.careerone.com.au +short @8.8.8.8

www.careerone.com.au.edgesuite.net.

a903.g.akamai.net.

208.44.23.99

208.44.23.121



Why does the above dig work when 



dig careerone.com.au +nssearch @8.8.8.8

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server usw1.akam.net in 106 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server usw4.akam.net in 136 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server usc4.akam.net in 124 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server usc1.akam.net in 40 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server usw5.akam.net in 190 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server ns1-24.akam.net in 171 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server asia1.akam.net in 161 ms.

SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600
1200 86400 1200 from server ns1-50.akam.net in 161 ms.



shows 8 auth nameservers for careerone.com.au



and if you use 



dig www.careerone.com.au +short @ 



you get no answer.



How does that work? Where does the 8.8.8.8 google public dns
server get its answer from?



  

www.careerone.com.au is an alias (through chained aliasing)
ultimately to a903.g.akamai.net. To get an authoritative answer for
a903g.akamai.net you'd need to ask one of the g.akamai.net
nameservers. Which is presumably what Google's public resolver did
to get the answers it returned to your query.



   
   
- Kevin

  


___
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

Re: question about how a particular dig works ...

[Kevin Darcy]

On 9/18/2012 12:59 PM, M. Meadows wrote:


Thanks Kevin. I understand how the chained alias works. Sorry, I 
didn't explain my question very well.


I can see that the 8.8.8.8 google public dns server gets an answer.

I know that this domain has a cname coexisting with an SOA record and 
NS records ... both of which I have read are a bad thing. And I've 
seen the other reply that indicates that this combination of records 
in a zone file wouldn't even load in BIND ... so it's done with some 
other more forgiving DNS app.


What I also see (but failed to explain) is that we have a local 
nameserver that can't find an answer to the dig www.careerone.com.au 
query. Gets no record back. Our local nameserver is an AD server that 
just throws up its imaginary hands in despair. So is this what we 
should expect from this problematic DNS setup in the 
www.careerone.com.au zone file? Erratic or somewhat erratic results? 
Just curious why google and some other public facing dns servers get 
an answer when our own local nameserver can't figure it out.





Date: Tue, 18 Sep 2012 11:18:58 -0400
From: k...@chrysler.com
To: bind-users@lists.isc.org
Subject: Re: question about how a particular dig works ...

On 9/18/2012 9:45 AM, M. Meadows wrote:


dig www.careerone.com.au  +short @8.8.8.8
www.careerone.com.au.edgesuite.net
.
a903.g.akamai.net.
208.44.23.99
208.44.23.121

Why does the above dig work when

dig careerone.com.au +nssearch @8.8.8.8
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server usw1.akam.net in 106 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server usw4.akam.net in 136 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server usc4.akam.net in 124 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server usc1.akam.net in 40 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server usw5.akam.net in 190 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server ns1-24.akam.net in 171 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server asia1.akam.net in 161 ms.
SOA dns0.news.com.au. hostmaster.news.com.au. 2012082200 3600 1200
86400 1200 from server ns1-50.akam.net in 161 ms.

shows 8 auth nameservers for careerone.com.au

and if you use

dig www.careerone.com.au  +short
@

you get no answer.

How does that work? Where does the 8.8.8.8 google public dns
server get its answer from?

www.careerone.com.au  is an alias 
(through chained aliasing) ultimately to a903.g.akamai.net. To get an 
authoritative answer for a903g.akamai.net you'd need to ask one of the 
g.akamai.net nameservers. Which is presumably what Google's public 
resolver did to get the answers it returned to your query.


It's possible that the CNAME-and-other error is causing Microsoft DNS to 
choke. Can you dump the cache on that box and see if it has records 
other than the CNAME?


Another possibility is that the CNAME chain is giving Microsoft DNS 
fits, although Akamai has been doing that for years and it seems to 
mostly work, despite being technically a violation of standards.


I don't know much about troubleshooting Microsoft DNS resolution 
problems, and I doubt many others on this list can (or would be willing 
to) help either. Maybe try a Microsoft list?


- Kevin
___
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-signzone ignoring "-x" option?

[Paul Wouters]

On Mon, 17 Sep 2012, Evan Hunt wrote:


Does anyone use dnssec-signzone with -x? If so, can you check/tell me
your DNSKEY RRset?



I just tested it with "dnssec-signzone -Sx example.com" and
"dnssec-signzone -x example.com", on 9.9.2 and 9.7.4, and it worked
as expected in all cases.

Were you signing your zone from scratch, or re-signing a zone that
was already signed?  If there was a pre-existing ZSK signature,
the signing process might have left it in place.


Bingo. That was the problem.

Thanks,

Paul
___
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

Inconsistent resolution

[Alan Batie]

We're having a very similar problem to the thread "question about how a
particular dig works ...", in that "dig +trace" works and "dig" doesn't
(which implies a problem with the local resolving named).

This particular story is that someone didn't get a domain renewed in
time (the oregonisonline.net domain that this domain uses for its
nameservers) and there's clearly polluted caches somewhere, but dig and
named are not being very helpful in tracking them down:

A "dig +trace" on a recursive resolver works fine, showing that the
chain has been properly restored and that particular resolver *can* get
the right data:

--
 [278] # dig +trace squarecirclers.org

; <<>> DiG 9.4.3-P1 <<>> +trace squarecirclers.org
;; global options:  printcmd
.   517515  IN  NS  m.root-servers.net.
.   517515  IN  NS  i.root-servers.net.
.   517515  IN  NS  l.root-servers.net.
.   517515  IN  NS  h.root-servers.net.
.   517515  IN  NS  d.root-servers.net.
.   517515  IN  NS  f.root-servers.net.
.   517515  IN  NS  a.root-servers.net.
.   517515  IN  NS  c.root-servers.net.
.   517515  IN  NS  e.root-servers.net.
.   517515  IN  NS  b.root-servers.net.
.   517515  IN  NS  k.root-servers.net.
.   517515  IN  NS  g.root-servers.net.
.   517515  IN  NS  j.root-servers.net.
;; Received 332 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

org.172800  IN  NS  a2.org.afilias-nst.info.
org.172800  IN  NS  b0.org.afilias-nst.org.
org.172800  IN  NS  a0.org.afilias-nst.info.
org.172800  IN  NS  d0.org.afilias-nst.org.
org.172800  IN  NS  c0.org.afilias-nst.info.
org.172800  IN  NS  b2.org.afilias-nst.org.
;; Received 438 bytes from 192.33.4.12#53(c.root-servers.net) in 36 ms

squarecirclers.org. 172800  IN  NS  ns1.oregonisonline.net.
squarecirclers.org. 172800  IN  NS  ns2.oregonisonline.net.
;; Received 90 bytes from 2001:500:f::1#53(d0.org.afilias-nst.org) in 86 ms

squarecirclers.org. 3600IN  A   207.55.97.142
squarecirclers.org. 3600IN  NS  ns2.oregonisonline.net.
squarecirclers.org. 3600IN  NS  ns1.oregonisonline.net.
;; Received 106 bytes from 50.57.78.108#53(ns2.oregonisonline.net) in 68 ms
--

A normal dig using that same nameserver's resolver fails, however:

--
 [279] # dig !$
dig squarecirclers.org

; <<>> DiG 9.4.3-P1 <<>> squarecirclers.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57824
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;squarecirclers.org.IN  A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 18 17:07:41 2012
;; MSG SIZE  rcvd: 36
--

This implies to me that the local nameserver has stale data, however
named has been restarted several times.  When I turn on logging, all it
tells me is "yup, got a query and went to look it up!", which isn't
terribly useful:

--
18-Sep-2012 16:42:14.661 queries: client 69.59.192.249#4192: query:
squarecirclers.org IN A +
18-Sep-2012 16:42:14.661 resolver: createfetch: squarecirclers.org A
--

On another nameserver that doesn't have the production traffic, a tshark
shows:

--
  6   6.389222 2607:f678::19:249 -> 2a01:348:0:15:5d59:5c7c:0:1 DNS
Standard query A squarecirclers.org
  7   6.389788 2a01:348:0:15:5d59:5c7c:0:1 -> 2001:500:40::1 DNS
Standard query A squarecirclers.org
  8   6.526514 2001:500:40::1 -> 2a01:348:0:15:5d59:5c7c:0:1 DNS
Standard query response
  9   6.527284 93.89.92.124 -> 192.52.178.30 DNS Standard query A
ns1.oregonisonline.net
 10   6.527449 93.89.92.124 -> 192.52.178.30 DNS Standard query 
ns1.oregonisonline.net
 11   6.527617 93.89.92.124 -> 192.52.178.30 DNS Standard query A
ns2.oregonisonline.net
 12   6.527763 93.89.92.124 -> 192.52.178.30 DNS Standard query 
ns2.oregonisonline.net
 13   6.543621 192.52.178.30 -> 93.89.92.124 DNS Standard query response
 14   6.543788 192.52.178.30 -> 93.89.92.124 DNS Standard query response
 15   6.544282 2a01:348:0:15:5d59:5c7c:0:1 -> 2001:500:f::1 DNS Standard
query A ns1.peak.org
 16   6.544401 2a01:348:0:15:5d59:5c7c:0:1 -> 2001:500:f::1 DNS Standard
query  ns1.peak.org
 17   6.544510 2a01:348:0:15:5d59:5c7c:0:1 -> 2001:500:f::1 DNS Standard
query A ns2.peak.org
 18   6.544609 2a01:348:0:15:5d59:5c7c:0:1 -> 2001:500:f::1 DNS Standard
query  ns2.peak.org
 19   6.545122 192.52.178.30 -> 93.89.92.124 DNS Standard query 

Re: Inconsistent resolution

[Mark Andrews]

Name servers cannot be cnames.  The DNS protocol cannot be made to
work reliably when they are CNAMEs without changing the definition
of glue and the additional section processing rules.  CNAME records
are NOT added as glue, A and  are added as glue.

ns1.oregonisonline.net. 3600IN  CNAME   ns1.peak.org.
ns1.peak.org.   3600IN  A   207.55.16.51

ns2.oregonisonline.net. 3600IN  CNAME   ns2.peak.org.
ns2.peak.org.   3600IN  A   50.57.78.108

If you want the nameservers to be ns1.peak.org and ns2.peak.org
update the NS records and update the delegation.  In the
meantime restore the A (and  records if they exist)
for ns1.oregonisonline.net and ns2.oregonisonline.net.

-- 
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