The nameservers for wikipedia.org are broken. They put the wrong
SOA record in the negative response, wikipedia.org != wikimedia.org.
M vs P
wikipedia.org. 86400 IN NS ns0.wikimedia.org.
wikipedia.org. 86400 IN NS ns1.wikimedia.org.
wikipedia.org. 86400 IN NS ns2.wikimedia.org.
;; Received 146 bytes from 2001:500:f::1#53(d0.org.afilias-nst.org) in 201 ms
wikimedia.org. 86400 IN SOA ns0.wikimedia.org.
hostmaster.wikimedia.org. 2011031404 43200 7200 1209600 600
;; Received 108 bytes from 91.198.174.4#53(ns2.wikimedia.org) in 335 ms
The adminstrators of wikimedia.org were informed about this months
ago but they don't seem to care. They fail to acknowledge the
problem or to fix the problem. wikimedia.org are not alone in this.
There are thousands on web sites that return the wrong answers to
lookups.
Meanwhile everyone wants resolver vendors to make the lookups work.
We can't when the authoritative servers are broken. It time the
users complained.
Mark
In message , Jay Fo
rd writes:
> A recursive resolver of mine running BIND 9.7.3 logs many messages like:
>
> resolver: DNS format error from 208.80.152.130#53 resolving \
> en.wikipedia.org/ for client ::1#33887: invalid response
> lame-servers: error (FORMERR) resolving 'en.wikipedia.org//IN': \
> 208.80.152.130#53
>
> I see this for a variety of domains, including wikipedia.org, yahoodns.net,
> officedepot.com, & staples.com. I did some investigation, including sniffing
> the DNS traffic. The problematic case seems to be names which have CNAMEs to
> names in other zones for which the queried record type doesn't exist. For
> example:
>
> en.wikipedia.org is a CNAME -> text.wikimedia.org
> text.wikimedia.org is a CNAME -> text.pmtpa.wikimedia.org
> text.pmtpa.wikimedia.org has an A record, but no , TXT...
>
> A query for type= name=en.wikipedia.org returns:
>
> % dig -t en.wikipedia.org
>
> ; <<>> DiG 9.7.3 <<>> -t en.wikipedia.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45218
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;en.wikipedia.org. IN
>
> ;; Query time: 229 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Wed Mar 16 11:34:08 2011
> ;; MSG SIZE rcvd: 34
>
> The response packet from the wikipedia/wikimedia DNS servers is:
>
> Internet Protocol, Src: 208.80.152.142 (208.80.152.142), \
>Dst: 128.255.204.16 (128.255.204.16)
> User Datagram Protocol, Src Port: 53 (53), Dst Port: 55497 (55497)
> Domain Name System (response)
> [Request In: 159]
> [Time: 0.061065000 seconds]
> Transaction ID: 0xd49c
> Flags: 0x8400 (Standard query response, No error)
> Questions: 1
> Answer RRs: 0
> Authority RRs: 1
> Additional RRs: 0
> Queries
> en.wikipedia.org: type , class IN
> Authoritative nameservers
> wikimedia.org: type SOA, class IN, mname ns0.wikimedia.org
>
> so, basically:
> code NOERROR
> no answer
> authority citing wikimedia.org
>
> NOERROR seems right, but it includes authority information for the zone of
> the CNAME target without including the CNAME as an answer, amounting to a
> mismatch between the original query & the cited authority.
>
> Note that if I do an A query first, I get the CNAME via a correctly formed
> response, after which the TXT & queries work, with the CNAME chain
> filled in from local cache.
>
> To me it looks like BIND is doing the right thing (as usual ;^), but the
> wikipedia... servers are returning bogus responses. Is this interpretation
> correct? If so, does anybody know what apparently screwy DNS server or
> configuration causes this behavior? I saw something similar with an F5
> installation here on campus briefly before I had the local folks fix it, but
> I'd like some confirmation that's what's going on with wikipedia... before I
> try to get them & others to fix it. Further, if it's a systemic F5...
> problem, then a different approach is probably in order.
>
>
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org
