Subject: [dnsext] And people complain when we want TCP as a MUST for DNS ...

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Mar 2010 11:56:40 +1100

------- Forwarded Message

Date: Tue, 16 Mar 2010 19:12:36 -0400
From: Robert Edmonds <[email-masked]>
To: [email-masked]
Message-ID: <[email-masked]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj"
Subject: [dns-operations] is there anyone from microsoft on the list?

- --9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

ns[1-5].msft.net are broken; they set the TC bit on certain UDP
responses but do not respond to TCP queries.

    microsoft.com has address 207.46.197.32
    microsoft.com has address 207.46.232.182
    microsoft.com mail is handled by 10 mail.messaging.microsoft.com.

    46.207.in-addr.arpa.    86400   IN  NS  ns1.msft.net.
    46.207.in-addr.arpa.    86400   IN  NS  ns2.msft.net.
    46.207.in-addr.arpa.    86400   IN  NS  ns5.msft.net.
    46.207.in-addr.arpa.    86400   IN  NS  ns4.msft.net.
    46.207.in-addr.arpa.    86400   IN  NS  ns3.msft.net.
    ;; Received 142 bytes from 2001:500:31::63#53(x.arin.net) in 105 ms

    $ dig +norec @ns1.msft.net -x 207.46.197.32
    ;; Truncated, retrying in TCP mode.

    ; <<>> DiG 9.7.0 <<>> +norec @ns1.msft.net -x 207.46.197.32
    ; (1 server found)
    ;; global options: +cmd
    ;; connection timed out; no servers could be reached

packet capture is attached.

- -- 
Robert Edmonds
[email-masked]

- --9amGYk9869ThD9tj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="msft_dns.txt"

No.     Time                       Source                Destination           Protocol Info
      1 2010-03-16 19:05:28.078902 216.27.162.2          65.55.37.62           DNS      Standard query PTR 32.197.46.207.in-addr.arpa

Frame 1 (86 bytes on wire, 86 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
User Datagram Protocol, Src Port: 50477 (50477), Dst Port: domain (53)
Domain Name System (query)
    [Response In: 2]
    Transaction ID: 0x0505
    Flags: 0x0000 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable
    Questions: 1
    Answer RRs: 0
    Authority RRs: 0
    Additional RRs: 0
    Queries
        32.197.46.207.in-addr.arpa: type PTR, class IN

No.     Time                       Source                Destination           Protocol Info
      2 2010-03-16 19:05:28.174656 65.55.37.62           216.27.162.2          DNS      Standard query response PTR alacris.com PTR allsorted.co.nz PTR alpineskihouse.com PTR alpineskihouse.net PTR 400plusdifferences.ca PTR 5iantlavalamp.com PTR academiczone.ch PTR activeviews.com PTR activeviews.net PTR adatum.com PTR adatum.net PTR adatum.org PTR adventure-works.com PTR adventure-works.net PTR adventure-works.org PTR ageofmythology.com

Frame 2 (530 bytes on wire, 530 bytes captured)
Ethernet II, Src: Unispher_a0:dc:be (00:90:1a:a0:dc:be), Dst: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c)
Internet Protocol, Src: 65.55.37.62 (65.55.37.62), Dst: 216.27.162.2 (216.27.162.2)
User Datagram Protocol, Src Port: domain (53), Dst Port: 50477 (50477)
Domain Name System (response)
    [Request In: 1]
    [Time: 0.095754000 seconds]
    Transaction ID: 0x0505
    Flags: 0x8600 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..1. .... .... = Truncated: Message is truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... .... 0000 = Reply code: No error (0)
    Questions: 1
    Answer RRs: 16
    Authority RRs: 0
    Additional RRs: 0
    Queries
        32.197.46.207.in-addr.arpa: type PTR, class IN
    Answers
        32.197.46.207.in-addr.arpa: type PTR, class IN, alacris.com
        32.197.46.207.in-addr.arpa: type PTR, class IN, allsorted.co.nz
        32.197.46.207.in-addr.arpa: type PTR, class IN, alpineskihouse.com
        32.197.46.207.in-addr.arpa: type PTR, class IN, alpineskihouse.net
        32.197.46.207.in-addr.arpa: type PTR, class IN, 400plusdifferences.ca
        32.197.46.207.in-addr.arpa: type PTR, class IN, 5iantlavalamp.com
        32.197.46.207.in-addr.arpa: type PTR, class IN, academiczone.ch
        32.197.46.207.in-addr.arpa: type PTR, class IN, activeviews.com
        32.197.46.207.in-addr.arpa: type PTR, class IN, activeviews.net
        32.197.46.207.in-addr.arpa: type PTR, class IN, adatum.com
        32.197.46.207.in-addr.arpa: type PTR, class IN, adatum.net
        32.197.46.207.in-addr.arpa: type PTR, class IN, adatum.org
        32.197.46.207.in-addr.arpa: type PTR, class IN, adventure-works.com
        32.197.46.207.in-addr.arpa: type PTR, class IN, adventure-works.net
        32.197.46.207.in-addr.arpa: type PTR, class IN, adventure-works.org
        32.197.46.207.in-addr.arpa: type PTR, class IN, ageofmythology.com

No.     Time                       Source                Destination           Protocol Info
      3 2010-03-16 19:05:28.174993 216.27.162.2          65.55.37.62           TCP      36441 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392853086 TSER=0 WS=7

Frame 3 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 36441 (36441), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
      4 2010-03-16 19:05:31.173753 216.27.162.2          65.55.37.62           TCP      36441 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392853836 TSER=0 WS=7

Frame 4 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 36441 (36441), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
      5 2010-03-16 19:05:37.173256 216.27.162.2          65.55.37.62           TCP      36441 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392855336 TSER=0 WS=7

Frame 5 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 36441 (36441), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
      6 2010-03-16 19:05:38.175171 216.27.162.2          65.55.37.62           TCP      38087 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392855586 TSER=0 WS=7

Frame 6 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 38087 (38087), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
      7 2010-03-16 19:05:41.173250 216.27.162.2          65.55.37.62           TCP      38087 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392856336 TSER=0 WS=7

Frame 7 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 38087 (38087), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
      8 2010-03-16 19:05:47.173754 216.27.162.2          65.55.37.62           TCP      38087 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392857836 TSER=0 WS=7

Frame 8 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 38087 (38087), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
      9 2010-03-16 19:05:48.175344 216.27.162.2          65.55.37.62           TCP      50340 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392858086 TSER=0 WS=7

Frame 9 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 50340 (50340), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
     10 2010-03-16 19:05:51.173253 216.27.162.2          65.55.37.62           TCP      50340 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392858836 TSER=0 WS=7

Frame 10 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 50340 (50340), Dst Port: domain (53), Seq: 0, Len: 0

No.     Time                       Source                Destination           Protocol Info
     11 2010-03-16 19:05:57.173255 216.27.162.2          65.55.37.62           TCP      50340 > domain [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=392860336 TSER=0 WS=7

Frame 11 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: IntelCor_3d:c4:7c (00:15:17:3d:c4:7c), Dst: Unispher_a0:dc:be (00:90:1a:a0:dc:be)
Internet Protocol, Src: 216.27.162.2 (216.27.162.2), Dst: 65.55.37.62 (65.55.37.62)
Transmission Control Protocol, Src Port: 50340 (50340), Dst Port: domain (53), Seq: 0, Len: 0

- --9amGYk9869ThD9tj
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dns-operations mailing list
[email-masked]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

- --9amGYk9869ThD9tj--

------- End of Forwarded Message

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 16 Mar 2010 21:41:04 -0700

Has anyone confirmed that the cause of this issue is that the DNS
software Microsoft is using lacks TCP support, and not that they've
simply misconfigured their software and/or network?

draft-ietf-dnsext-dns-tcp-requirements simply requires DNS software to
implement TCP support.  It's been argued here that it doesn't require
operators to actually enable TCP support, so unless the issue does
turn out to be lack of TCP support, this is a straw man.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 17 Mar 2010 02:11:29 -0300

Here's a question, which may bring things back on topic even if the OP wasn't:

Should DNS software *signal* that it understands TCP but has had TCP
disabled by the operator?
Certainly this is preferable to silently ignoring TCP queries...

That would disambiguate the perception from external observers.

E.g. RCODE=4 (not implemented) if the software doesn't support TCP, vs
RCODE=5 (refused) if the TCP support is administratively disabled?

Maybe that should be added to the tcp-requirements document?

(I am of the opinion that implementations should not support disabling
TCP, but that's just my opinion...)

(Rate-limit is vastly different from disable, BTW...)

Brian

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Mar 2010 05:36:23 +0000

> Date: Wed, 17 Mar 2010 02:11:29 -0300
> From: Brian Dickson <[email-masked]>
> 

not directly.  those rcodes are talking about opcodes that are implemented
or not, or allowed or not.  to talk about transports that aren't supported
or aren't permitted, new rcodes would have to be allocated.

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Mar 2010 08:39:55 +0000

> disabled by the operator?

No. For one thing, it's a layering violation. For another, I fail to  
see what use this signal could be. If a server isn't reachable over  
TCP, why would anything (need to) care about why TCP traffic isn't  
getting through? It's not going to make any difference to how a  
resolver will behave or could behave in that situation. DNS over TCP  
simply isn't going to work and it doesn't matter to the resolver why  
that's the case. Next, it's highly improbable the DNS software could  
know for sure that TCP has been disabled by the operator: for instance  
DNS/TCP could be getting dropped by some third party in the path  
between resolver and server. Finally, introducing this sort of flag  
opens up a rat-hole for more flags in this genre: eg EDNS is  
understood but blocked, EDNS packets bigger than N bytes are supported  
but blocked, dynamic update is understood but blocked, queries for  
classes other than IN are blocked by something, AXFRs or IXFRs are  
blocked before they get to the server, etc, etc.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 17 Mar 2010 12:12:42 +0000

> simply misconfigured their software and/or network?

Of course, their current implementation supports TCP.  I would be
suprised if older versions were different.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Mar 2010 05:44:10 -0700

> suprised if older versions were different.

Its amazing the number of networks that "do things" to DNS that the network operators even don't know about, which we see with Netalyzr (ob plug: http://netalyzr.icsi.berkeley.edu/ )

EG, our test on UDP is both real DNS and a bogus request/response: The bogus one is filtered out with alarming regularity, and we've had cases of "no, we don't do anything to DNS on our network..."  "oh wait, the XYZ firewall has a DNS module thats active by default..."

Our TCP test is non-protocol, so if we get a connection then failure, its protocol-violation blocking or proxing, vs connection refused (which is just blocking)

We also check that the resolver does failover to TCP right in the current version:
truncate.{garbage}.{node}.netalyzr.icsi.berkeley.edu returns truncated on UDP, and only responds "right" on TCP.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 17 Mar 2010 13:01:31 +0000

--On 17 March 2010 05:44:10 -0700 Nicholas Weaver 
<[email-masked]> wrote:

> EG, our test on UDP is both real DNS and a bogus request/response: The
> bogus one is filtered out with alarming regularity, and we've had cases
> of "no, we don't do anything to DNS on our network..."  "oh wait, the XYZ
> firewall has a DNS module thats active by default..."

Or in Cisco's case, "our router has a module that is partly active even when
deactivated".

-- 
Alex Bligh