On Thu, 4 Jan 2007, Edward Lewis wrote:
> At 13:15 -0500 1/4/07, Dean Anderson wrote:
>
> >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. Those who think there is some "universally correct"
> >answer have no legitimate foundation for that belief. They are really
> >just trying to impose their _site's_ practices on everyone else in the
> >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
> >be achieved even if everyone were to adopt their practices. [ignoring
> >the fact that some sites cannot adopt those practices and have very good
> >reasons for their different practices.]
> I can speak to the motivation of this because I think I was the one
> that suggested the words.
>
> The motivation had nothing to do with security. Your point is well
> taken and I agree that there is little value in the reverse map in
> providing security. (Arguably, some value, not enough to justify the
> expense certainly.)
Hmm. So, the word change had nothing to do with security. The draft and
its advocates _do_ still assert that there is security in matching
forward/reverse. The IETF can't change their belief, but it can avoid
the use of vague language with dual interpretations that is designed to
support that belief.
> But the vagueness ot the text is borne from other observed uses of
> DNS, for example Akamization and what some call "directional DNS".
> There are folks that purposefully answer differently based on where a
> query comes from. It can be argued that these folks are violating
> coherency and they can retort that no, they are abusing dynamic update
> (with a wink). Whatever, it happens, and we need to recognize reality
> and not try to argue theory.
Akamization or (directional DNS) has nothing to do with reverse DNS.
They give out different A records depending on the query source.
Frankly, I can see nothing wrong with this, either. Some people object
to this practice, but their objection can't be founded in the text of
existing DNS RFCs. The coherency argument is a red-herring, since a
long-cached record only "hurts" akamai, not anyone else. Akamai, etc can
give out 0 TTL records to avoid that, if they choose to. It doesn't
seem that transforming the in-addr draft will provide text that makes
this behavior non-standard. If that is the goal of this draft, then it
is really coming in "under the radar". I don't read the text of this
draft as affecting directional DNS.
> The other scenario I had in mind was split-DNS, in which I answer
> with more detail to my own machines than the Internet. Such as -
> Inside: 8.88.888.202.in-addr.arpa PTR amadeus.perl.example.
> Outside: 8.88.888.202.in-addr.arpa PTR machine888888.perl.example.
>
> The "outside" isn't always to hide the inside machine's true
> identity, but this makes transitions inside transparent to the
> outside. Especially if the inside is using some kind of dynamic
> update via DHCP and I just don't want to deal with that headache
> outside my firewall.
{suggestion: run two sets of nameservers, one set with public
information, and another set with inside information}
Regarding the draft: Same as above for directional DNS. The split-dns
purpose seems to be "under the radar", and the text of this draft
doesn't seem to alter the issue of split-DNS.
> I think you are right in discounting the notion of "universally
> correct" answers. But if so, I would think you would even more agree
> with the words as stated.
You are discussing issues of "universial consistency" of many/all types
of records. I am concerned about the definition of "correct PTR
response".
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
