-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
We should keep nice and descriptive subject-lines...
Michel Py wrote:
| etc. Basically everything that triggers a reverse lookup adds to the
| pain, but if reverse lookup is configured correctly on the local DNS
A lot of the arguments seem to contai
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| (2) But the typical plug-and-play NAT, at least the ones I have run
| across, is preconfigured with the addresses to be used on the "inside"
| and contains (or is intimately paired with) a DHCP server that gives out
| those addresses. Installing
--On Wednesday, 15 October, 2003 22:10 +0200 Leif Johansson
<[EMAIL PROTECTED]> wrote:
| (2) But the typical plug-and-play NAT, at least the ones I
| have run across, is preconfigured with the addresses to be
| used on the "inside" and contains (or is intimately paired
| with) a DHCP server tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| Leif,
|
| I was speaking to the architectural issue, not the deployment one. None
| of the three plug and play boxes I have here with NAT capability has any
| inside DNS capability (either enabled by default or available to be
| turned on).
Exact
On 15 okt 2003, at 23:09, Leif Johansson wrote:
Of course (I am beeing intentionally obtuse) but isn't it quite
unlikely
that any recommendation the we make at this point will have any impact
RFC 2827 provides exactly these recommendations. Unfortunately many
operators still can't be bothered or
Leif / Iljitsch,
>>> It does sound like a recommendation to the effect of "if you are
going
>>> to use NAT, or construct a NAT box, then an 'inside DNS' mechanism"
>>> would be a reasonable idea. And I would assume it would be an even
>>> better one if it made clear what the preferred way was
On 15 okt 2003, at 23:24, Michel Py wrote:
RFC 2827 provides exactly these recommendations.
[FYI: RFC 2827 is about ingress filtering to stop source address
spoofing]
Does it? We are not talking about blocking RFC1918 traffic here;
I was.
what we
are talking is blocking traffic where both SA(af
At 05:24 PM 10/15/2003, Michel Py wrote:
Leif / Iljitsch,
>>> It does sound like a recommendation to the effect of "if you are
going
>>> to use NAT, or construct a NAT box, then an 'inside DNS' mechanism"
>>> would be a reasonable idea. And I would assume it would be an even
>>> better one if it
> Keith will not like it, but NAT vendors will take suggestions that
> will make NAT better.
I'd be happy for them to take suggestions from me, or IETF. But there's
a big difference between saying "if you must do NAT, please do it this
way" and "NATs are good if they are implemented this way"
Daniel / Iljitsch,
> Daniel Senie wrote:
> [NAT box acting as a DNS server]
> It also may be ill-advised, unless a switch is present for disabling
it.
Of course.
> While we can argue ISPs should not use RFC 1918 space, there are
> many using it, including some who use it because their equipment
Remember that Reverse lookups are optional. Many people who start of
saying "if reverse dns is configured correctly..." don't seem to
understand that reverse DNS is also properly configured when it is turned
off.
The abuse, and the numerous security vulnerabilities which have been
introduced by th
> Intercept would be nice in the following situations:
> - When Joe Blow has configured a static IP and static DNS servers that
> point to the ISP's DNS servers instead of the NAT box.
so the next time Joe Blow is trying to figure out why a particular DNS server
isn't responding correctly by expli
>> Intercept would be nice in the following situations:
>> - When Joe Blow has configured a static IP and static DNS servers
that
>> point to the ISP's DNS servers instead of the NAT box.
> Keith Moore wrote:
> so the next time Joe Blow is trying to figure out why a particular
> DNS server isn't r
-BEGIN PGP SIGNED MESSAGE-
Dean Anderson wrote:
> Reverse DNS is probably not going to be working or widely used in
> IPV6, which has
> an alternate ICMP host information query so that reverse DNS is not
> necessary for the most useful purpose of reverse DNS: traceroute.
I think you und
So far, DNSSEC doesn't solve this problem. I don't think the reverse DNS
problem is intended to be solved by DNSSEC.
Quick poll: Does anyone actually think that DNS can be made globably
invulnerable, and positively trusted, yet usable?
DNSSEC won't solve a number of problems of intentional fal
-BEGIN PGP SIGNED MESSAGE-
Dean Anderson wrote:
> So far, DNSSEC doesn't solve this problem. I don't think the
> reverse DNS problem is intended to be solved by DNSSEC.
IMHO "reverse" is just the same as ordinary domains.
Where DNS is a phonebook for internet name mappings.
> Quick
On Fri, Oct 17, 2003 at 07:20:25PM -0400, Dean Anderson wrote:
> Perhaps all that is important is to remember that "properly configured
> Reverse DNS" includes having no reverse DNS at all.
Reverse DNS is just a zone in the in-addr.arpa domain. And there is more
to reverse DNS than just a untrustw
17 matches
Mail list logo
