Subject: UDP port numbers

From: Thomas Narten <[email-masked]>
Date: Tue, 13 Apr 1999 14:34:01 -0400

A client sends a UDP query to a DNS server. The server responds with a
UDP reply. What port numbers/addresses are required to be in the
reply? I.e., if the query goes out as:

Query: src addr=X, src port=Y, dest addr=dest, dest port=53

MUST the reply have a source addr of "dest", and MUST the src port=53?
Or can the source port (and/or address) be arbitrary, as is the case
in some protocols, such as tftp?

RFC 1035 is very illumniating (not) on the subject:

> 4.2.1. UDP usage
> 
> Messages sent using UDP user server port 53 (decimal).

I'm curious whether any other RFCs say more, and/or what
implementations actually require.

Context: there seems to be some variability here in what UDP protocols
actually do here, and there are implications for firewalls and NAT
devices.

Thomas

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 13 Apr 1999 21:06:55 -0700

BIND requires the source port of the reply to be the same as the destination
port of the request.

---

From: [email-masked]
Date: Wed, 14 Apr 1999 12:31:10 +1000

> actually do here, and there are implications for firewalls and NAT
	While it in not written down it is expected that responses
	will be sent from the address & port the query was sent to
	(unicast).  Broadcast / multicast response behaviour is
	not currently defined.
	
	Namservers go to a lot of trouble to achieve this as modern
	kernels don't provide the necessary hooks to do this easily.
	Older namservers on multihomed boxes just choose the "closest"
	address and port 53.  These however are becoming rarer and
	rarer.

	Resolvers (especially those in nameservers) often check
	the source address and port of answers they recieve and
	reject those that don't come from a address they queried.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Apr 1999 06:57:03 -0700 (PDT)

have you checked rfc2181?

---

From: Andrew Brown <[email-masked]>
Date: Tue, 13 Apr 1999 23:36:11 -0400

>in some protocols, such as tftp?

well...not necessarily, but if you wish to have any semblance of
security, they should be.  otherwise, how do you know someone didn't
just send you a bogus response?

>implementations actually require.

see rfc2181, section 4.

>actually do here, and there are implications for firewalls and NAT

if outbound queries make the firewall expect a response (as some do),
then they should only (imho) be required to expect a single response
within a small window (probably 90 seconds at the most?) from the
specified destination address and port as per the outbound query.

-- 
|-----< "CODE WARRIOR" >-----|
[email-masked]             * "ah!  i see you have the internet
[email-masked] (Andrew Brown)                that goes *ping*!"
[email-masked]       * "information is power -- share the wealth."

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 Apr 1999 10:00:57 -0400

> have you checked rfc2181?

I have now. :-) Thanks for all the pointers.

Thomas

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 13 Apr 1999 23:57:17 -0400

See RFC 2181, section 4.

Donald

From:  Thomas Narten <[email-masked]>
Message-Id:  <[email-masked]>
To:  [email-masked]
Date:  Tue, 13 Apr 1999 14:34:01 -0400

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Apr 1999 08:44:38 -0700 (PDT)

2181 says "SHOULD" not "MUST."  so what you describe is probably too
restrictive.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 14 Apr 1999 13:28:14 -0400

Actually, it says:

> 3. Terminology
> 
>    This memo does not use the oft used expressions MUST, SHOULD, MAY, or
>    their negative forms.   In some sections it may seem that a
>    specification is worded mildly, and hence some may infer that the
>    specification is optional.  That is not correct.  Anywhere that this
>    memo suggests that some action should be carried out, or must be
>    carried out, or that some behaviour is acceptable, or not, that is to
>    be considered as a fundamental aspect of this specification,
>    regardless of the specific words used.  If some behaviour or action
>    is truly optional, that will be clearly specified by the text.

So it tries to make all shoulds be SHOULD, and all musts be
MUST. Then, it goes on to say:

> 4.2. Port Number Selection
> 
>    Replies to all queries must be directed to the port from which they
			    ^^^^
>    were sent.  When queries are received via TCP this is an inherent
>    part of the transport protocol.  For queries received by UDP the
>    server must take note of the source port and use that as the
	    ^^^^
>    destination port in the response.  Replies should always be sent from
						^^^^^^
>    the port to which they were directed.  Except in extraordinary
>    circumstances, this will be the well known port assigned for DNS
>    queries [RFC1700].

I.e, it uses both "should" and "must". Sigh. Here is where having a
SHOULD would have the practical effect of overriding the must (or vice
versa) and removing the ambiguity.

Thomas

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 14 Apr 1999 11:41:30 -0700

>> BIND requires the source port of the reply to be the same as the
>> destination port of the request.

> 2181 says "SHOULD" not "MUST."  so what you describe is probably too

from a standards point of view that's true: it's too restrictive.

from a security point of view that's false: it solved a problem i actually had.

i guess the right answer from a marketing point of view is to make it optional.

(but then we have to argue about the default.  sigh.)

this behaviour of bind predates rfc2181 btw.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Apr 1999 11:56:51 -0400

This is in RFC 2181 (Clarify), section 4.2.  So it is a DNS requirement too.

>BIND requires the source port of the reply to be the same as the destination

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                       Network Associates/TIS
Phone: +1 443-259-2352                             Email: [email-masked]

Think globally, scope locally.
"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda

Opinions expressed are property of my evil twin, not my employer.

---

From: Thomas Narten <[email-masked]>
Date: Thu, 15 Apr 1999 07:02:02 -0400

>    destination port in the response.  Replies should always be sent from
					^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    the port to which they were directed.  Except in extraordinary
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    circumstances, this will be the well known port assigned for DNS

"should always" != MUST????

And if BIND is too restrictive, just how should it be more liberal? If
it accepts responses from any source port, than forcing the server to
use any particular source port would not appear to serve a useful
purpose.

Thomas

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Apr 1999 07:51:57 -0700 (PDT)

>>    destination port in the response.  Replies should always be sent from

talk to a co-author who is less than enthused about 2119.

> And if BIND is too restrictive, just how should it be more liberal?

it was the source ADDRESS, not the source PORT which we were discussing.

randy

---

From: Alan Barrett <[email-masked]>
Date: Fri, 16 Apr 1999 09:30:52 +0000 (GMT)

> "should always" != MUST????

I think you missed this part of RFC 2181:

   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
   their negative forms.  [...]  If some behaviour or action
   is truly optional, that will be clearly specified by the text.

--apb (Alan Barrett)