incorrect handling of wildcard dns entries
Jehiah Czebotar
google dns seems to be responding with a wildcard entry when it should not
# detail
we have a dns record for labs.bit.ly that points to two addresses, and
a wildcard entry for *.bit.ly that points to 5 different addresses.
google dns (ie: 8.8.8.8) has the correct information for nameservers
yet returns an incorrect response compared to the authoritative name
server for labs.bit.ly. Also, I can confirm that no change has been
made for longer than the ttl for the wildcard entry (1800 seconds).
This problem is intermittent as 8.8.8.8 will sometimes return the
correct response for labs.bit.ly. the error has been confirmed and
observed multiple times and an example output is below.
# dig output
correct response:
$dig labs.bit.ly @ns1.p26.dynect.net
; <<>> DiG 9.6.0-APPLE-P2 <<>> labs.bit.ly @ns1.p26.dynect.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42286
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;labs.bit.ly. IN A
;; ANSWER SECTION:
labs.bit.ly. 150 IN A 168.143.173.37
labs.bit.ly. 150 IN A 168.143.173.49
;; AUTHORITY SECTION:
bit.ly. 86400 IN NS ns3.p26.dynect.net.
bit.ly. 86400 IN NS ns1.p26.dynect.net.
bit.ly. 86400 IN NS ns4.p26.dynect.net.
bit.ly. 86400 IN NS ns2.p26.dynect.net.
;; Query time: 8 msec
;; SERVER: 208.78.70.26#53(208.78.70.26)
;; WHEN: Fri Dec 18 09:36:13 2009
;; MSG SIZE rcvd: 147
incorrect response from google dns
$dig labs.bit.ly @8.8.8.8
; <<>> DiG 9.6.0-APPLE-P2 <<>> labs.bit.ly @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19422
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;labs.bit.ly. IN A
;; ANSWER SECTION:
labs.bit.ly. 1200 IN A 168.143.174.29
labs.bit.ly. 1200 IN A 128.121.234.46
labs.bit.ly. 1200 IN A 128.121.254.129
labs.bit.ly. 1200 IN A 128.121.254.201
labs.bit.ly. 1200 IN A 128.121.254.205
labs.bit.ly. 1200 IN A 168.143.174.25
;; Query time: 142 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec 18 09:39:33 2009
;; MSG SIZE rcvd: 125
a correct response from google dns
$dig labs.bit.ly @8.8.8.8
; <<>> DiG 9.6.0-APPLE-P2 <<>> labs.bit.ly @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6699
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;labs.bit.ly. IN A
;; ANSWER SECTION:
labs.bit.ly. 145 IN A 168.143.173.49
labs.bit.ly. 145 IN A 168.143.173.37
;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Dec 18 09:36:54 2009
;; MSG SIZE rcvd: 61
our wildcard entry
$dig '*.bit.ly' @ns1.p26.dynect.net
; <<>> DiG 9.6.0-APPLE-P2 <<>> *.bit.ly @ns1.p26.dynect.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48462
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 4, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;*.bit.ly. IN A
;; ANSWER SECTION:
*.bit.ly. 1800 IN A 168.143.174.29
*.bit.ly. 1800 IN A 128.121.234.46
*.bit.ly. 1800 IN A 128.121.254.129
*.bit.ly. 1800 IN A 128.121.254.201
*.bit.ly. 1800 IN A 128.121.254.205
*.bit.ly. 1800 IN A 168.143.174.25
;; AUTHORITY SECTION:
bit.ly. 86400 IN NS ns4.p26.dynect.net.
bit.ly. 86400 IN NS ns3.p26.dynect.net.
bit.ly. 86400 IN NS ns1.p26.dynect.net.
bit.ly. 86400 IN NS ns2.p26.dynect.net.
;; Query time: 6 msec
;; SERVER: 208.78.70.26#53(208.78.70.26)
;; WHEN: Fri Dec 18 09:40:28 2009
;; MSG SIZE rcvd: 208
--
Jehiah
Alex Nizhner
# summary
google dns seems to be responding with a wildcard entry when it should not
# detail
we have a dns record for labs.bit.ly that points to two addresses, and
a wildcard entry for *.bit.ly that points to 5 different addresses.
google dns (ie: 8.8.8.8) has the correct information for nameservers
yet returns an incorrect response compared to the authoritative name
server for labs.bit.ly. Also, I can confirm that no change has been
made for longer than the ttl for the wildcard entry (1800 seconds).
This problem is intermittent as 8.8.8.8 will sometimes return the
correct response for labs.bit.ly. the error has been confirmed and
observed multiple times and an example output is below.
The reason this is happening is that some of the authorities for bit.ly are still returning the old records. The bit.ly zone has four authorities listed with .ly:
[finwe]% dig +norec @NS-LY.RIPE.NET labs.bit.ly
; <<>> DiG 9.4.2-P2.1 <<>> +norec @NS-LY.RIPE.NET labs.bit.ly
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5421
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 0
bit.ly. 172800 IN NS ns3.zoneedit.com.
bit.ly. 172800 IN NS ns18.zoneedit.com.
bit.ly. 172800 IN NS ns1.p26.dynect.net.
bit.ly. 172800 IN NS ns2.p26.dynect.net.
When I try the dynect.net nameservers for labs.bit.ly, I get the new 2-record response, as you show below. On the other hand, the zoneedit ones give the 6-record response:
[finwe]% dig +norec @ns3.zoneedit.COM labs.bit.ly
; <<>> DiG 9.4.2-P2.1 <<>> +norec @ns3.zoneedit.COM labs.bit.ly
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11405
;; flags: qr aa; QUERY: 1, ANSWER: 6, AUTHORITY: 2, ADDITIONAL: 0
labs.bit.ly. 1200 IN A 168.143.174.29
labs.bit.ly. 1200 IN A 128.121.234.46
labs.bit.ly. 1200 IN A 128.121.254.129
labs.bit.ly. 1200 IN A 128.121.254.201
labs.bit.ly. 1200 IN A 128.121.254.205
--
========================================================
You received this message because you are subscribed to the Google
Groups "public-dns-discuss" group.
To post to this group, send email to public-dn...@googlegroups.com
To unsubscribe from this group, send email to
public-dns-disc...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/public-dns-discuss?hl=en
For more information on Google Public DNS, please visit
http://code.google.com/speed/public-dns
========================================================
Jehiah Czebotar
thanks =)
--
Jehiah