In article ,
Sam Wilson wrote:

> Has anyone else noticed this? Is there anything that can be done about
> it? Results are consistent across ns[1-5].msft.net and may be
> implicated in some problems we had looking up www.microsoft.com earlier
> today.

While this isn't good practice, I'm not sure how it could cause
problems. There's no normal path through DNS that should cause you to
query the Microsoft servers for root information.

I suspect they've done this to combat people who (perhaps maliciously)
register domains and delegate them to the Microsoft servers. Their
server returns an authoritative NOERROR response for any domains they
don't actually host.

$ dig www.foo.com a @ns1.msft.net +norec

; <<>> DiG 9.2.2 <<>> www.foo.com a @ns1.msft.net +norec
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57098
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.foo.com. IN A

;; AUTHORITY SECTION:
.. 3600 IN SOA ns1.msft.net. msnhst.microsoft.com. 2006031159
3600 600 604800 3600

>
> midge:~ swilson$ dig . soa @ns1.msft.net
>
> ; <<>> DiG 9.2.2 <<>> . soa @ns1.msft.net
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32647
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;. IN SOA
>
> ;; ANSWER SECTION:
> . 3600 IN SOA ns1.msft.net.
> msnhst.microsoft.com. 2006031159 3600 600 604800 3600
>
> ;; ADDITIONAL SECTION:
> ns1.msft.net. 3600 IN A 207.68.160.190
>
> ;; Query time: 163 msec
> ;; SERVER: 207.68.160.190#53(ns1.msft.net)
> ;; WHEN: Tue Apr 25 12:12:09 2006
> ;; MSG SIZE rcvd: 101
>
> midge:~ swilson$ dig . ns @ns1.msft.net
>
> ; <<>> DiG 9.2.2 <<>> . ns @ns1.msft.net
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4278
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 5
>
> ;; QUESTION SECTION:
> ;. IN NS
>
> ;; ANSWER SECTION:
> . 172800 IN NS ns2.msft.net.
> . 172800 IN NS ns3.msft.net.
> . 172800 IN NS ns4.msft.net.
> . 172800 IN NS ns5.msft.net.
> . 172800 IN NS ns1.msft.net.
>
> ;; ADDITIONAL SECTION:
> ns2.msft.net. 3600 IN A 65.54.240.126
> ns3.msft.net. 3600 IN A 213.199.144.151
> ns4.msft.net. 3600 IN A 207.46.66.75
> ns5.msft.net. 3600 IN A 65.55.238.126
> ns1.msft.net. 3600 IN A 207.68.160.190
>
> ;; Query time: 163 msec
> ;; SERVER: 207.68.160.190#53(ns1.msft.net)
> ;; WHEN: Tue Apr 25 12:12:01 2006
> ;; MSG SIZE rcvd: 195
>
>
> Sam Wilson one of hostmaster@ed.ac.uk
> Infrastructure Services Division
> Computing Services, The University of Edinburgh
> Edinburgh, Scotland, UK

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article ,
Barry Margolin wrote:

> In article ,
> Sam Wilson wrote:
>
> > [ WRT Microsoft servers with their own root SOA and NS records ]
>
> > Has anyone else noticed this? Is there anything that can be done about
> > it? Results are consistent across ns[1-5].msft.net and may be
> > implicated in some problems we had looking up www.microsoft.com earlier
> > today.
>
> While this isn't good practice, I'm not sure how it could cause
> problems. There's no normal path through DNS that should cause you to
> query the Microsoft servers for root information.

Earlier today we were getting this answer from one of our local servers:

su-2.05b# dig www.microsoft.com @129.215.200.7

; <<>> DiG 9.3.0 <<>> www.microsoft.com @129.215.200.7
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46369
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;www.microsoft.com. IN A

;; ANSWER SECTION:
www.microsoft.com. 305 IN CNAME toggle.www.ms.akadns.net.
toggle.www.ms.akadns.net. 53 IN CNAME g.www.ms.akadns.net.

;; AUTHORITY SECTION:
g.www.ms.akadns.net. 162 IN CNAME lb1.www.ms.akadns.net.
.. 302 IN SOA ns1.msft.net.
msnhst.microsoft.com. 2006031159 3600 600 604800 3600

;; Query time: 18 msec
;; SERVER: 129.215.200.7#53(129.215.200.7)
;; WHEN: Tue Apr 25 11:02:35 2006
;; MSG SIZE rcvd: 158

Which caused some hiccups. 129.215.200.7 is running BIND 8.something
and I'm certainly open to the idea that that might have a bug which
caused it to stumble over this particular lookup, but we hadn't noticed
this kind of problem before.

The server log has lots of messages like these:

Apr 25 14:10:10 cancer named[2514]: [ID 295310 local4.info] wrong ans.
name (ticketmaster.webtrends.akadns.net != wt.ticketmaster.akadns.net)
Apr 25 14:10:10 cancer named[2514]: [ID 295310 local4.warning] late
CNAME in answer section for wt.ticketmaster.akadns.net A from
[69.45.78.3].53

with many more of the "wrong ans. name" messages then the "late CNAME"
ones. Most refer to akadns.net domains but I'm unable to tie any
message up to the Microsoft mislookup.


Sam Wilson one of hostmaster@ed.ac.uk
Infrastructure Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK

In article ,
Sam Wilson wrote:

> In article ,
> Barry Margolin wrote:
>
> > In article ,
> > Sam Wilson wrote:
> >
> > > [ WRT Microsoft servers with their own root SOA and NS records ]
> >
> > > Has anyone else noticed this? Is there anything that can be done about
> > > it? Results are consistent across ns[1-5].msft.net and may be
> > > implicated in some problems we had looking up www.microsoft.com earlier
> > > today.
> >
> > While this isn't good practice, I'm not sure how it could cause
> > problems. There's no normal path through DNS that should cause you to
> > query the Microsoft servers for root information.
>
> Earlier today we were getting this answer from one of our local servers:
>
> su-2.05b# dig www.microsoft.com @129.215.200.7
>
> ; <<>> DiG 9.3.0 <<>> www.microsoft.com @129.215.200.7
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46369
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;www.microsoft.com. IN A
>
> ;; ANSWER SECTION:
> www.microsoft.com. 305 IN CNAME toggle.www.ms.akadns.net.
> toggle.www.ms.akadns.net. 53 IN CNAME g.www.ms.akadns.net.
>
> ;; AUTHORITY SECTION:
> g.www.ms.akadns.net. 162 IN CNAME lb1.www.ms.akadns.net.
> . 302 IN SOA ns1.msft.net.
> msnhst.microsoft.com. 2006031159 3600 600 604800 3600
>
> ;; Query time: 18 msec
> ;; SERVER: 129.215.200.7#53(129.215.200.7)
> ;; WHEN: Tue Apr 25 11:02:35 2006
> ;; MSG SIZE rcvd: 158
>
> Which caused some hiccups. 129.215.200.7 is running BIND 8.something
> and I'm certainly open to the idea that that might have a bug which
> caused it to stumble over this particular lookup, but we hadn't noticed
> this kind of problem before.

It's definitely confused, but I'm not sure how the strange configuration
of ns1.msft.net could be causing it. When I query ns1.msft.net for
www.microsoft.com, all it returns is the CNAME record, NOT the root
records.

What's weird in the above response is that the third CNAME record
belongs in the ANSWER section -- I'm not sure how it's getting into the
AUTHORITY section. That seems to be what it's complaining about when it
refers to "late CNAME". The only records that should ever be in the
Authority section are NS records (for delegations) or an SOA record (in
negative responses).

>
> The server log has lots of messages like these:
>
> Apr 25 14:10:10 cancer named[2514]: [ID 295310 local4.info] wrong ans.
> name (ticketmaster.webtrends.akadns.net != wt.ticketmaster.akadns.net)

Interesting. I do technical support for Symantec enterprise firewall
appliances, and yesterday we noticed one of our customer's firewalls
recently reporting the analogous complaint about that exact same name.
I couldn't reproduce it in our lab, though. Basically, what that error
means is that the response is missing the CNAME record, i.e. when you
ask the server to look up ticketmaster.webtrends.akadns.net, instead of
returning

ANSWER SECTION:
ticketmaster.webtrends.akadns.net. IN CNAME wt.ticketmaster.akadns.net.
wt.ticketmaster.akadns.net. IN A

it's just returning

ANSWER SECTION:
wt.ticketmaster.akadns.net. IN A

I'm not sure how this happens. Are you forwarding to your ISP's server,
or doing your own iterative resolution?

> Apr 25 14:10:10 cancer named[2514]: [ID 295310 local4.warning] late
> CNAME in answer section for wt.ticketmaster.akadns.net A from
> [69.45.78.3].53
>
> with many more of the "wrong ans. name" messages then the "late CNAME"
> ones. Most refer to akadns.net domains but I'm unable to tie any
> message up to the Microsoft mislookup.
>
>
> Sam Wilson one of hostmaster@ed.ac.uk
> Infrastructure Services Division
> Computing Services, The University of Edinburgh
> Edinburgh, Scotland, UK

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article ,
Barry Margolin wrote:

> In article ,
> Sam Wilson wrote:
>
> > In article ,
> > Barry Margolin wrote:
> >
> > > In article ,
> > > Sam Wilson wrote:
> > >
> > > > [ WRT Microsoft servers with their own root SOA and NS records ]
> > >
> > > > Has anyone else noticed this? Is there anything that can be done about
> > > > it? Results are consistent across ns[1-5].msft.net and may be
> > > > implicated in some problems we had looking up www.microsoft.com earlier
> > > > today.
> > >
> > > While this isn't good practice, I'm not sure how it could cause
> > > problems. There's no normal path through DNS that should cause you to
> > > query the Microsoft servers for root information.
> >
> > Earlier today we were getting this answer from one of our local servers:
> >
> > su-2.05b# dig www.microsoft.com @129.215.200.7
> >
> > ; <<>> DiG 9.3.0 <<>> www.microsoft.com @129.215.200.7
> > ;; global options: printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46369
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;www.microsoft.com. IN A
> >
> > ;; ANSWER SECTION:
> > www.microsoft.com. 305 IN CNAME toggle.www.ms.akadns.net.
> > toggle.www.ms.akadns.net. 53 IN CNAME g.www.ms.akadns.net.
> >
> > ;; AUTHORITY SECTION:
> > g.www.ms.akadns.net. 162 IN CNAME lb1.www.ms.akadns.net.
> > . 302 IN SOA ns1.msft.net.
> > msnhst.microsoft.com. 2006031159 3600 600 604800 3600
> >
> > ;; Query time: 18 msec
> > ;; SERVER: 129.215.200.7#53(129.215.200.7)
> > ;; WHEN: Tue Apr 25 11:02:35 2006
> > ;; MSG SIZE rcvd: 158
> >
> > Which caused some hiccups. 129.215.200.7 is running BIND 8.something
> > and I'm certainly open to the idea that that might have a bug which
> > caused it to stumble over this particular lookup, but we hadn't noticed
> > this kind of problem before.
>
> It's definitely confused, but I'm not sure how the strange configuration
> of ns1.msft.net could be causing it. When I query ns1.msft.net for
> www.microsoft.com, all it returns is the CNAME record, NOT the root
> records.

Same here for nsI.msft.net, I=1..5.

> What's weird in the above response is that the third CNAME record
> belongs in the ANSWER section -- I'm not sure how it's getting into the
> AUTHORITY section. That seems to be what it's complaining about when it
> refers to "late CNAME". The only records that should ever be in the
> Authority section are NS records (for delegations) or an SOA record (in
> negative responses).

Indeed. But the . SOA record looks as though it could only have come
from one of the nsI.msft.net servers. I've been trying to replicate the
lookup sequence. To me it looks like this:

www.microsoft.com gets referred by . and .com servers to nsI.msft.net
which respond with

www.microsoft.com. 3600 IN CNAME toggle.www.ms.akadns.net.

We then look for toggle.www.ms.akadns.net, getting referrals from . and
..net to a whole bunch of akadns.net servers -
(asia4|asia9|eur4|eur7|eur8|usc4|use1|use9|usw5|us w6|usw7).akadns.net.
With the exception of usw7 these all respond strangely:

; <<>> DiG 9.2.2 <<>> toggle.www.ms.akadns.net. @asia4.akadns.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16111
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:
;toggle.www.ms.akadns.net. IN A

;; ANSWER SECTION:
toggle.www.ms.akadns.net. 300 IN CNAME g.www.ms.akadns.net.
g.www.ms.akadns.net. 300 IN CNAME lb1.www.ms.akadns.net.

;; AUTHORITY SECTION:
.. 1000 IN NS H.ROOT-SERVERS.net.
.. 1000 IN NS G.ROOT-SERVERS.net.
.. 1000 IN NS B.ROOT-SERVERS.net.
.. 1000 IN NS M.ROOT-SERVERS.net.
.. 1000 IN NS D.ROOT-SERVERS.net.
.. 1000 IN NS L.ROOT-SERVERS.net.
.. 1000 IN NS E.ROOT-SERVERS.net.
.. 1000 IN NS K.ROOT-SERVERS.net.

;; ADDITIONAL SECTION:
H.ROOT-SERVERS.net. 1000 IN A 128.63.2.53
G.ROOT-SERVERS.net. 1000 IN A 192.112.36.4
B.ROOT-SERVERS.net. 1000 IN A 192.228.79.201
M.ROOT-SERVERS.net. 1000 IN A 202.12.27.33
D.ROOT-SERVERS.net. 1000 IN A 128.8.10.90
L.ROOT-SERVERS.net. 1000 IN A 198.32.64.12
E.ROOT-SERVERS.net. 1000 IN A 192.203.230.10
K.ROOT-SERVERS.net. 1000 IN A 193.0.14.129

;; Query time: 259 msec
;; SERVER: 61.213.147.96#53(asia4.akadns.net)
;; WHEN: Wed Apr 26 16:02:21 2006
;; MSG SIZE rcvd: 337

That's not exactly a lame response since the answer includes one further
step in the chain but fails to give the final response (the A RRset for
lb1.www.ms.akadns.net) which the servers are apparently authoritative
for.

usw7.akadns.net does give the sensible response (though, even though I
know the order of RRs in a response is not significant, that still looks
bizarre to me):

; <<>> DiG 9.2.2 <<>> toggle.www.ms.akadns.net. @usw7.akadns.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53975
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;toggle.www.ms.akadns.net. IN A

;; ANSWER SECTION:
g.www.ms.akadns.net. 300 IN CNAME lb1.www.ms.akadns.net.
lb1.www.ms.akadns.net. 300 IN A 207.46.199.30
lb1.www.ms.akadns.net. 300 IN A 207.46.18.30
lb1.www.ms.akadns.net. 300 IN A 207.46.19.60
lb1.www.ms.akadns.net. 300 IN A 207.46.20.60
lb1.www.ms.akadns.net. 300 IN A 207.46.19.30
lb1.www.ms.akadns.net. 300 IN A 207.46.198.60
toggle.www.ms.akadns.net. 300 IN CNAME g.www.ms.akadns.net.

;; Query time: 163 msec
;; SERVER: 65.203.234.28#53(usw7.akadns.net)
;; WHEN: Wed Apr 26 16:02:23 2006
;; MSG SIZE rcvd: 172

Asking all the partially lame servers for the A records for
lb1.www.ms.akadns.net explicitly works fine.


> > The server log has lots of messages like these:
> >
> > Apr 25 14:10:10 cancer named[2514]: [ID 295310 local4.info] wrong ans.
> > name (ticketmaster.webtrends.akadns.net != wt.ticketmaster.akadns.net)
>
> Interesting. I do technical support for Symantec enterprise firewall
> appliances, and yesterday we noticed one of our customer's firewalls
> recently reporting the analogous complaint about that exact same name.
> I couldn't reproduce it in our lab, though. Basically, what that error
> means is that the response is missing the CNAME record, i.e. when you
> ask the server to look up ticketmaster.webtrends.akadns.net, instead of
> returning
>
> ANSWER SECTION:
> ticketmaster.webtrends.akadns.net. IN CNAME wt.ticketmaster.akadns.net.
> wt.ticketmaster.akadns.net. IN A
>
> it's just returning
>
> ANSWER SECTION:
> wt.ticketmaster.akadns.net. IN A
>
> I'm not sure how this happens. Are you forwarding to your ISP's server,
> or doing your own iterative resolution?

The server is not forwarding - our 'ISP' doesn't offer that service.

I think I'm leaning towards something being weird at akadns.net. I'm
guessing they're not running a nameserver I'd recognise.


Sam Wilson one of hostmaster@ed.ac.uk
Infrastructure Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK

In article ,
Sam Wilson wrote:

> I think I'm leaning towards something being weird at akadns.net. I'm
> guessing they're not running a nameserver I'd recognise.

Me too. Their DNS architecture is a proprietary feature of their
service, which is geographically distributed load balancing.

And the name lb1.www.ms.akadns.net suggests more Load Balancing.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***