Microsoft root servers? - TCP-IP

This is a discussion on Microsoft root servers? - TCP-IP ; 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. midge:~ swilson$ dig . soa @ns1.msft.net ; ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Microsoft root servers?

  1. Microsoft root servers?

    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.

    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

  2. Re: Microsoft root servers?

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

  3. Re: Microsoft root servers?

    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

  4. Re: Microsoft root servers?

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

  5. Re: Microsoft root servers?

    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

  6. Re: Microsoft root servers?

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

+ Reply to Thread