Subject: Re: UDP port numbers

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

> > 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
> > 
> 	While it in not written down
	 see below
>	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]
	
	I really should remember to read RFC 2181: Clarifications
	to the DNS Specification.  See Section 4, Server Reply Source
	Address Selection.

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

---

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

Thomas Narten <[email-masked]> writes:
> 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.

Never mind. I can't read today.

Thomas

---

From: Robert Elz <[email-masked]>
Date: Thu, 15 Apr 1999 12:05:08 +1000

Message-Id: <[email-masked]>
    Subject: Re: UDP port numbers 
    Date: Wed, 14 Apr 1999 13:28:14 -0400
    From: Thomas Narten <[email-masked]>

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

No, in essence, it makes all of them be a must.   There is no 2119 crapola
in 2181.

    I.e, it uses both "should" and "must".

Yes, but for two different things.   It uses the "must" to refer to the
destination port in a reply (which must be to the source port of the
query).   No-one doubts this at all, or it would not be a reply.
It is only there because of rumours that some implementation, sometime,
would send all DNS packets to port 53 (queries, responses, everything).
I doubt there was ever such a beast, but ...

The "should" is for the source port in a reply.  1035 places no restrictions
on that, and in theory, none should be needed.  But in a practical sense (if
you want the process at the other end to associate the reply with the query
it sent) this is what you have to do.

    Sigh. Here is where having a
    SHOULD would have the practical effect of overriding the must (or vice
    versa) and removing the ambiguity.

There is no ambiguity I am aware of.

kre