On Thu, 4 Jan 2007, Andrew Sullivan wrote:
> Since as a matter of history it's a revival of that draft under a
> different filename (as some people objected to the "required"), that
> shouldn't be too surprising.
That's good the title has changed, then. I'm glad for that. I thought
the draft was dropped, but I must have been mistaken.
> > In general, the DNS response to a reverse map query for an address
> > ought to reflect what is supposed to be seen at the address by the
> > machine initiating the query.
> >
> > There is no exact definition of "what is supposed to be seen at the
> > address by the machine initiating the query". This incorrect assertion
> > is at the very heart of the mistaken uses of 'reverse DNS as security
> > mechanism'. The correct answer to "what is supposed to be seen" is
> > _site_ dependent.
>
> The point of the "supposed to" and "by the machine initiating the query"
> language is precisely to capture that site dependency that you,
> quite correctly, point out. If you have another way to state that, a
> patch to the text is welcome. If you think it's unclear, please
> suggest the language that will make that intention clearer.
Right. The disagreement is that your camp thinks there must be an
affirmative answer to a PTR query that must match a forward name, where
my camp asserts that NXdomain is proper response, and that no matching
forward is also correct. Obviously, changing your words will not
resolve this disagreement. [I seem to recall a 10+message exchange where
different words expressing the same notion were proposed]
It is not the description of your notion that is disputed. It it the
notion itself.
Somewhat, over time your camp may have moderated the notion from "MUST"
to "SHOULD", but "SHOULD" is still incorrect: Reverse records are
entirely optional. Matching reverse with forward is entirely optional.
It is perfectly valid to give (eg) the very same contents (eg "av8.com")
for every reverse record. Or not have any reverse records at all. No bad
things should result from any of these practices or any other reverse
practice.
I've seen admins claim that PTR records of the form
"h-11-22-33-44.somedomain.com" are suspicious. This is complete
nonsense---emphasize "complete", because there is no valid assumption
for what might or might not be "suspicious" or untrustworthy
_whatsoever_. This message needs to very clear and prominent in any
draft encouraging reverse DNS use.
> > Those who think there is some "universally correct" answer have no
> > legitimate foundation for that belief.
>
> Of course there is no universally correct answer; see above. What I
> claim is true, though, is this: since DNS is deterministic, there is
> a right answer to every _particular_ query, when the particulars of
> the query include its origin.
Technically, DNS is not deterministic: Caches can quite naturally give
out different answers to same query depending on when they queried the
authority and how long they have cached that response. [not only can the
principal answer change, but the TTL can also change] So the answer you
get depends on the cache chosen, and this may be done at random.
[indeed, I've found that a surprising number of caches don't respect
TTLs. Anycast'd caches are even more non-deterministic]
There are no definitely right answers. There are only definitely wrong
answers: those that originate from somewhere other than the authority.
> > belief that if everyone else did what they did, they could use reverse
> > DNS for security or anti-spam or some such. The ends, however, cannot
>
> I think the draft says that you should not rely on reverse DNS for
> security, and that more importantly, if you decide to, you'd better
> be aware of the consequences. If that isn't clear, please tell me
> where I can make it clearer.
How about this text in SECURITY CONSIDERATIONS
===============
DNS PTR records are entirely optional, and MUST NOT be assumed to exist.
Software MUST NOT fail or incur delay as a result of the non-existance
of PTR records.
DNS MUST NOT be relied on for security or trust decisions. Even when
DNSSEC is used to verify the authenticity of DNS records, matching
reverse and forward records do not imply either improved security or
trustworthiness over sites that either do not have reverse DNS or that
do not have matching foward/reverse DNS.
DNS records MUST NOT be used in logs in place of IP addresses.
===============
> And I think the draft _also_ says that there may indeed be some cases
> where those different practices are in fact a good idea. We've
> included some.
The draft seems to say "if you don't do reverse mapping, bad things
happen and you should expect this". That message is incorrect and needs
to be removed. The unfounded expectations for reverse DNS records are
illegitimate, and should not be given legitimacy by description in the
draft. There should be no cases of uses of reverse DNS (for forward/
reverse matching), but rather only cases of how people _provide_ reverse
DNS to illustrate the diversity of reverse DNS provisioning.
There are no valid assumptions for what should be found when one makes a
PTR query. So many of the use cases you describe are based on invalid
assumptions. Drafts should not contain invalid assumptions.
"PTR records are like a box of chocolate. You never know what you'll
get" --Dean Anderson (2007) [you can put that in the draft ;-)]
> I did discuss this at the San Diego meeting, and I note the
> discussion made it into the jabber notes and the minutes. I also have
> put all the issues into the tracker, so you could have a look at
> them there if you'd like.
Thanks. I tried to connect to jabber at the montreal meeting, but I
couldn't get any of 3 different windows clients to work....I'm not a
jabber user. Too bad there isn't an IRC gateway...
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
