Subject: trustworthy MX->A caching

From: "D. J. Bernstein" <[email-masked]>
Date: 7 Dec 1999 09:09:49 -0000

RFC 2181 says that additional records ``should not be cached in such a
way that they would ever be returned as answers to a received query.''
It also says that ``should'' means ``must.''

For example, say an MTA does an MX query. Its nearby caching resolver
resolves the MX query and receives

   internic.net MX 100 rs.internic.net
   rs.internic.net A 198.41.0.6

from the internic.net servers. The MTA then does an A query. (In theory,
the MTA could find the additional record and skip the second query. In
practice, resolv.h is a pain to use, so MTAs rely on resolver caches.)

The resolver is now required by RFC 2181 to pester the internic.net
servers again, rather than providing the A record. Right?

I don't understand what the RFC 2181 rules are supposed to achieve. If
the goal is to prevent cache poisoning, the RFC 2181 rules are neither
necessary nor sufficient. As an example of possible poisoning, consider
the records

   munnari.oz.au MX 10 munnari.oz.au
   munnari.oz.au MX 80 cougar.esec.com.au
   cougar.esec.com.au A 203.21.84.4

from the server dmssyd.syd.dms.csiro.au. RFC 2181 allows the A record to
be cached and returned as additional data for subsequent queries; but
that's a security hole. The resolver must discard the A record.

(The MTA situation is actually more complicated than shown above,
because MTAs start with an initial * query to check for CNAME records.
In practice, however, this * query is usually satisfied by NS records,
so MTAs continue with MX and A queries.)

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Dec 1999 09:35:06 +1100

Date:        7 Dec 1999 09:09:49 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | For example, say an MTA does an MX query. Its nearby caching resolver
  | resolves the MX query and receives
  | 
  |    internic.net MX 100 rs.internic.net
  |    rs.internic.net A 198.41.0.6
  | 
  | from the internic.net servers. The MTA then does an A query.

  | The resolver is now required by RFC 2181 to pester the internic.net
  | servers again, rather than providing the A record. Right?

It could perhaps be read that way, but wasn't intended to be.   The 1034/1035
model provides a distinction between servers and resolvers.  That has largely
been blown away by BIND, but leave that aside for now.   The theory is that
a server provides answers, a resolver obtains and uses them.  2181 was trying
to say that a server should (== must) not use answers from the additional
section to populate its cache, and then return it later in the answer
section.   Resolvers on the other hand ought use all of the data they're
given (or all of it they decide to trust), the resolver only hands the data
back to the application that invoked it.

Now all that gets messy and difficult with the bind model, where the
resolver associated with the application is dumb in the extreme, and the
smarter part of it is inextricably intertwined with the server code,
but that doesn't alter the overall model - it just makes it very
difficult to implement rationally.

  | I don't understand what the RFC 2181 rules are supposed to achieve. If
  | the goal is to prevent cache poisoning, the RFC 2181 rules are neither
  | necessary nor sufficient.

Perhaps not, but the general belief was that they would help in many
cases.   Perfection might not be achieved, but a small amount of bad
data is better than a large amount of bad data - blindly caching and
returning data from the additional section of replies had contributed
to vast amounts of bad data that was very difficult to remove.

If you have a better rule that would achieve even better results, and
is actually implementable, then we should consider that for a revised 2181.

  | As an example of possible poisoning, consider the records
  | 
  |    munnari.oz.au MX 10 munnari.oz.au
  |    munnari.oz.au MX 80 cougar.esec.com.au
  |    cougar.esec.com.au A 203.21.84.4

I am confused.   You seen to be suggestion that those are all answers.
When I query dmssyd.syd.dms.csiro.au I get the first two of those in the
answer section, and the third as additional data.   This is exactly the
same as the situation you mentioned above.

  | from the server dmssyd.syd.dms.csiro.au. RFC 2181 allows the A record to
  | be cached and returned as additional data for subsequent queries; but
  | that's a security hole. The resolver must discard the A record.

Oh I see - because dmssyd is not authoritative for esec.com.au.   I guess
it could discard it - but as long as it does not promote the security
of the record - it received the A record as additional data, so handing
it on as additional data should do no particular harm.   If it is sent
(as additional data) to a server that will believe it, that is no
different than if that other server had obtained the same data from
dmssyd as additional data.  If the other server isn't going to trust
stray additional data from dmssyd, then it won't trust it from the
other server which has passed it along.

While this kind of "security" (really just attempting to limit the effects
of bad data) certainly doesn't provide much additional confidence,
experience has shown that having servers be very conservative about
what data they are spreading around has helped improve the reliability of
the DNS greatly (you may remember back a few years when there was almost
as much bogus (usually outdated) data floating around as the real stuff).

Any kind of real security is awaiting the more widespread use of SIG
records.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Dec 1999 00:11:26 -0000

Robert Elz writes:
> it received the A record as additional data, so handing
> it on as additional data should do no particular harm.

Wrong. Say the local MTA asks for the munnari.oz.au MX record. The oz.au
server says

   munnari.oz.au MX whc.eop.gov
   whc.eop.gov A 1.2.3.4

and the MTA's nearby cache remembers whc.eop.gov A 1.2.3.4. Later on,
the MTA asks for the whitehouse.gov MX record. Some server says

   whitehouse.gov MX whc.eop.gov

to which the cache adds whc.eop.gov A 1.2.3.4. The oz.au server has now
misdirected whitehouse.gov mail.

As I said before, the cache has to throw this A record away, even though
the RFC 2181 rules allow the cache to keep it as additional data.

If, on the other hand, the oz.au server provides an additional record
saying blah.oz.au A 1.2.3.4, then the cache can trust that record, even
though the RFC 2181 rules prohibit providing the record as an answer.

The complicated distinctions that RFC 2181 draws between answers and
additional records do not accurately capture the difference between
names in the server's domain and names outside the server's domain.

> the general belief was that they would help in many cases.

Help _what_? Once again: What are these rules supposed to accomplish?
Justification is notably absent from RFC 2181.

---Dan

---

From: [email-masked]
Date: Wed, 08 Dec 1999 12:34:10 +1100

The reason for these rules is basically to stop glue being
	promoted to answers.

	If you #define NOADDITIONAL in BIND you nearly get correct
	behaviour.  It's been a while since I turned it on (read years)
	so there may be a corner case that needs fixing.

	Mark

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

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Dec 1999 12:55:53 +1100

Date:        8 Dec 1999 00:11:26 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The oz.au server has now misdirected whitehouse.gov mail.

Yes, that can happen.

  | If, on the other hand, the oz.au server provides an additional record
  | saying blah.oz.au A 1.2.3.4, then the cache can trust that record,

No it can't, no more than the other one, it is just as likely to be
wrong (blah.oz.au might be delegated elsewhere).

Alternatively, the oz.au server asked might have been authoritative
for whc.eop.gov - that it is an oz.au server doesn't mean it cannot
also be an a server for eop.gov.

The only thing the AA bit covers is the answer, anything in the
additional section might be stray data, or might not be, unless it
relates to the same name as appears in the answer, you simply can't tell.

There is nothing in 2181 that will protect in any way against malicious
bad data, on the other hand, it does seem to help protect against
accidental pollution.   What is in 2181 was largely derived from the
changes made to bind, or thought useful to be applied to bind, to
help avoid the continual spread of bad data that older versions
had "encouraged".

  | The complicated distinctions that RFC 2181 draws between answers and
  | additional records do not accurately capture the difference between
  | names in the server's domain and names outside the server's domain.

No, they don't - but there is nothing in the format of a DNS answer that
allows that distinction to be drawn, nothing at all.  That is, except
that the answer is authoritative (assuming AA is set) and nothing else is.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Dec 1999 04:28:08 -0000

The situation here is the standard ``stub resolver'' situation shown on
page 7 of RFC 1035. Here's how mail delivery normally works in the
common case of an on-site MX:

   MTA                    cache                         oz.au server
   (stub resolver)        (recursive server)
   -----------------------------------------------------------------
       munnari.oz.au MX?
       -----------------> 
                                     munnari.oz.au MX?
                                     -----------------> 

                                     munnari.oz.au MX blah.oz.au
                                     blah.oz.au A 1.2.3.4
                                    <--------------------

       munnari.oz.au MX blah.oz.au
       blah.oz.au A 1.2.3.4
      <--------------------

       blah.oz.au A? (for reasons that I explained before)
       -------------> 

       blah.oz.au A 1.2.3.4
      <--------------------

RFC 2181 clearly says that the cache must not return this A record.
Instead it has to send another query to the oz.au server. What exactly
does the cache gain by doing this?

I'm not saying that the extra time or traffic is a big deal. I'm asking
for a coherent explanation of why I should teach my new cache about the
RFC 2181 rules.

> > saying blah.oz.au A 1.2.3.4, then the cache can trust that record,

The oz.au server is usually the best source that the cache knows for the
blah.oz.au address; as an architectural matter, it has control over that
address. Do you seriously expect the cache to discard the address---and
then ask the same server for the same address?

The situation is completely different when the oz.au server provides an
additional record for whc.eop.gov. There is, in general, no reason that
a cache would ask that server for that information; having the cache
repeat the record in any way is clearly wrong.

By the way, why do you say that parent servers are ``just as likely'' as
untrusted outside servers to have incorrect information? It seems to me
that parents are the first to be fixed when a server address changes,
while glue stored elsewhere can last for months.

---Dan

---

From: [email-masked]
Date: Wed, 08 Dec 1999 17:50:57 +1100

>    (stub resolver)        (recursive server)

	Because blah.oz.au is not served by the same servers as oz.au.
	The servers for oz.au should generate a referral to the servers
	for blah.oz.au if it learnt the record through glue / additional
	section processing.  Which you would then query for blah.oz.au/A.

	The fact the BIND does not do this at present is down to
	architectual limitations in the BIND 4/8 code.  BIND 9 does not
	have those limitations.

> for a coherent explanation of why I should teach my new cache about the

	Because in the absence of signed data it trues the cache.

> then ask the same server for the same address?

	Yes.  You don't know if it has control or has delegated it.

> while glue stored elsewhere can last for months.
	Experience shows they are.

> ---Dan

	I've been running nameservers for around 10 years now (Kre's been
	running them longer still).  We both have had to deal with the
	wrong IP address for servers we have been running getting into
	hundreds (if not thousands) of zone files and then having to
	get those wrong address purged from the system.

	Appling heuristics like those in 2181 made this a managable task.
	It wasn't when we started.

	Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Dec 1999 10:06:59 -0000

All caching clients have to protect themselves against cache poisoning
by discarding records outside the server's bailiwick (i.e., the owner
domain in the NS record that gave the server's address).

I've already given an example to demonstrate that caching such records
as ``additional only'' is unsafe: it allows corrupted data to spread and
hurt other people, the same way that normal caching would.

[email-masked] writes:
> We both have had to deal with the wrong IP address for servers we have
> been running getting into hundreds (if not thousands) of zone files
> and then having to get those wrong address purged from the system.

Once all clients are protected against cache poisoning, the only servers
with the power to spread iengines.com information are the root servers,
the .com servers, and the iengines.com servers.

What precisely is the extra benefit to drawing various artificial lines
between authoritative answers, non-authoritative answers, authoritative
additional records, etc.? If your parent servers are misbehaving, you're
screwed in any case.

By the way, if clients hadn't been vulnerable to cache poisoning in the
first place, other servers wouldn't have bothered sending your data as
additional records. The administrators, in turn, wouldn't have tried to
add your names to their zones.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Wed, 08 Dec 1999 18:59:05 +1100

Date:        8 Dec 1999 04:28:08 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The situation here is the standard ``stub resolver'' situation shown on
  | page 7 of RFC 1035. Here's how mail delivery normally works in the
  | common case of an on-site MX:

Yes, I know the standard setup.   It is a pity it works that way, rather
than having the mailer simply get the MX and A record (back to its
resolver library routine) and not even need to query the cache again.

never mind.

  | RFC 2181 clearly says that the cache must not return this A record.
  | Instead it has to send another query to the oz.au server. What exactly
  | does the cache gain by doing this?

Probably not a lot.   But if you really care about the most accurate
data possible, you need to send the extra query, the A in the additional
info section might have come from nowhere.

  | The oz.au server is usually the best source that the cache knows for the
  | blah.oz.au address; as an architectural matter, it has control over that
  | address. Do you seriously expect the cache to discard the address---and
  | then ask the same server for the same address?

Since we have mostly been using real data in this, and blah.oz.au doesn't
exist, let me show you the problem (well, the rationale) using a real
example (well, a mostly real example, I'm not sure what query would
result in the A record appearing in the additional data section).

Instead of blah.oz.au, let's use erm.oz.au - assume that you got

	erm.oz.au. IN A 192.100.22.100

from an oz.au server in the additional data section (I assume that
erm.oz.au is the MX for some oz.au name or other, though I don't actually
know of one, and would have to hunt harder than it is worth to find
a real example).

Your assumption is that this A record comes from the oz.au zone file
(as glue, or authoritative data) - it wouldn't, it would simply be
something that happens to have found its way into the cache.  The
actual data in the oz.au zone file for erm.oz.au is ...

erm.oz.au.      86400   NS      earth.ermapper.com.AU.
erm.oz.au.      86400   NS      bitter.ermapper.com.AU.

That name is delegated to servers that have nothing at all to do with oz.au.
Those two servers are the source of the A record (and the only true source).

This is no different at all to your whc.eop.gov example.   You are assuming
some relationship between similar looking names which simply does not
exist in the DNS.

  | The situation is completely different when the oz.au server provides an
  | additional record for whc.eop.gov. There is, in general, no reason that
  | a cache would ask that server for that information; having the cache
  | repeat the record in any way is clearly wrong.

Given the erm.oz.au example above (you can go query the oz.au servers and
discover this date for yourself to verify it) can you see that the two cases
are exactly parallel.   It may be that the oz.au server is an authoritative
source for either whc.eop.gov or erm.oz.au purely by co-incidence - in this
case it happens that it is for neither.   On the other hand, if the two names
were reg1.usp.ac.fj and ipso.ips.oz.au and the oz.au server that had been
queried was munnari.oz.au, then the additional info would (in both cases)
be authoritative, as munnari.oz.au is a server for both usp.ac.fj and
ips.oz.au (and neither reg1.usp.ac.fj nor ipso.ips.oz.au is delegated).

There simply is no way to tell from an answer what data in the additional
section is likely to be valid, and which is less likely - any attempt to
do so by guessing from the names (except where the name is the same one
that apepars in the answer - as in munanri.oz.au. in mx munnari.oz.au
and munnari.oz.au. in a 128.250.1.21 in the additional info) is simply
doomed to failure.   Don't even think of going there.

  | By the way, why do you say that parent servers are ``just as likely'' as
  | untrusted outside servers to have incorrect information? It seems to me
  | that parents are the first to be fixed when a server address changes,
  | while glue stored elsewhere can last for months.

You are assuming that the data in the parent comes from delegation glue.
As demonstrated above, not at all true, it can come from anywhere.

Further, as one who runs a fairly busy delegation point, I can assure you
that parent domains don't get updated when child zones change data, 
including when the parent zone used to be a secondary server as well, and
is to be no longer...   You'd be amazed at how much extremely poor
management of DNS information there is.  But that is besire the point.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 8 Dec 1999 10:03:29 -0000

The fact that the roots control all names, that the oz.au servers
control all names under oz.au, etc., is a fundamental architectural
feature of DNS. It is built into the DNS resolution procedure.

Domains ending with oz.au exist only at the whim of the oz.au servers.
If those servers declare that erm.oz.au has address 1.2.3.4, then, as
far as DNS clients are concerned, erm.oz.au has address 1.2.3.4. Perhaps
the oz.au server administrators will be sued for negligence or breach of
contract, but this doesn't change the semantics of their DNS records.

In contrast, if (say) rip.psg.com declares that (say) munnari.oz.au has
address 5.6.7.8, then it is talking about a name outside its control. As
far as DNS clients are concerned, munnari.oz.au has two address records,
128.250.1.21 and 128.250.22.2. The information from rip.psg.com is an
attempt at cache poisoning.

> Your assumption is that this A record comes from the oz.au zone file

Where do you get these ideas? I said nothing of the sort. The client
doesn't care how the oz.au servers acquired their information.

---Dan

---

From: Terry Lambert <[email-masked]>
Date: Wed, 08 Dec 1999 10:20:51 -0800

>        munnari.oz.au MX blah.oz.au

The cache gains nothing, per se, unless you want to allow
it to answer authoritatively for the A record, in which case
it gains everything.

Consider the case of a standard (dumb) client that does
not cache data, because it is not given the TTL values by
the API, so it has no idea how long such an entry can be
validly cached.

The value in an MX doing a reverse lookup, then a forward
lookup (which is the real behaviour of most MXs) is that
the reverse lookup relies on the in-addr.arpa delegation
of the IP address, whereas the forward lookup relies on
the names delegation of the au.oz domain.

The use of multiple delegation authorities provides the
client machine with verification that the reverse address
has not been spoofed, with a spoofed forward address that
is sent back as "additional information".

This means that I can not hack a DNS server to lie to you,
provide you additional (unsolicited) information, and then
get you to foolishly believe it, merely because I control
the DNS server that has the legal delegation for the IP
address in in-addr.arpa, but _not_ the legal delegation
for the domain name in au.oz.

This issue is either an outgrowth of the use of DNS data
for an MX crosscheck, or the result of a system that was
not designed for use by intentionally malicious users
(moderately fixed by TSIG, leaving only a small replay
window).

> I'm not saying that the extra time or traffic is a big
> deal. I'm asking for a coherent explanation of why I
> should teach my new cache about the RFC 2181 rules.

So that it doesn't accidently falsify data to its users
because of a malicious intermediate server, I would think.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Dec 1999 09:15:35 +1100

Date:        8 Dec 1999 10:03:29 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The fact that the roots control all names, that the oz.au servers
  | control all names under oz.au, etc., is a fundamental architectural
  | feature of DNS. It is built into the DNS resolution procedure.

No, it is not.   This is quite eimply wrong.   Delegation changes
the control of the zone data - any data that has been delegated is the
responsibility of the party delegated to.

The nature of the resolution process, if implemented the shortcut
way (the effecient way) allows parent domains to (sometimes) alter the data
that a sloppy client will see, it does not make the parent responsible for
that data, and it does not allow the parent to claim to be an authority
for that data.

That is, using the example I used last night, if you ask an oz.au
sesrver for the A record for erm.oz.au you will NOT get an answer
with the AA bit set (except in the one case where it was a recursive
query to a server that has RA=1, and the reply returned is one that the
server just obtained and that reply had AA set - ie: it is simple relaying
of information) - no more than if you ask a server for yp.to for the A
record for erm.oz.au.   The server will provide any "knowledge" that it
happens to have acquired, from anywhere.  Unless AA is set, and the
RR is in the answer section, clients should not treat that answer specially
in any way because of which server happened to return it.   If the client
is principally concerned with effeciency, it may choose to believe any
data it receives, returned from anywhere - just so it can be used as
quickly as possible.   If the client puts reliability above effeciency
then it must obtain an authoritative answer.   (And if the client
desires authenticity, it must also obtain SIG records and verify them).

Note that a parent cannot reliably exercise the kind of control you assume -
once the resolver has found the NS records for the delegation point (perhaps
from being included in the authority section of a previous reply for a similar
name) the resolver will go direct to the child zone, skipping the chain down
from the root completely.   If it were a "fundamental architectural
feature of DNS" that the parent have control of all names within its
domain, rather than within its zone, then that kind of short circuit
resolution could not be permitted, all name resolution would have to
start from the root zone, always, in order to implement that architectural
design.   Further, clients would be required to always perform the short
cut style resolution (that is most common) instead of being permitted to
do full blown (sluggish) resolution, which they are now permitted to
do ... that is, to start with a query to the root servers for the NS
records for AU, and then having obtained that (which is non AA glue)
ask those servers for the NS records for AU.  Unless the DNS tree has been
completely broken, at least one (and hopefully all) of the servers provided
by the root server will provide a NS list for AU with AA=1.   Then the
AU servers have been reliably located.  Then ask the servers for AU for
the NS records for oz.au and use those to find the NS list with AA=1 (in this
case you might get lucky, and the AU server selected might happen to be auth
for oz.au as well - but that is mere coincidence) and then ask the oz.au
servers for the NX records for erm.oz.au, and those for the auth set of
NS records for erm.oz.au continuing until either NS records for the
domain name wanted have been discovered, or until one of the servers
down the chain indicates that no more NS records exist.   Then, unless
NXDOMAIN was returned as well, the last servers located can be asked
for any data desired about the domain name, and you know you are getting
the answer from an auth source for that particular name.

This is permitted by the DNS - it isn't done that way often (though I
often do that kind of resolution manually when I really want to know what
some data should be) because it adds way too much overhead.  But your
imagined fundamental architecture would forbid it, and nothing does that.

  | Domains ending with oz.au exist only at the whim of the oz.au servers.

The existance of such things, yes, they do - the oz.au zone gets to
create the names in oz.au.   Further it can choose to be authoritative
for them, or it can choose to delegate them.   But once delegated, the
responsibility for the data belongs to the delagee.

  | If those servers declare that erm.oz.au has address 1.2.3.4, then, as
  | far as DNS clients are concerned, erm.oz.au has address 1.2.3.4.

No, not if the domain has been delegated.   The AA bit in the reply exists
precisely to distinguish the cases where the data is being supplied
authortatively, and where it is not.

  | In contrast, if (say) rip.psg.com declares that (say) munnari.oz.au has
  | address 5.6.7.8, then it is talking about a name outside its control.

Yes, and it (unless it is broken, or relaying an AA reply) would not set the 
AA bit.   No more than munnari.oz.au (an oz.au server) will set the AA bit
when returning the A record for erm.oz.au (unless it is relaying an AA reply).
The two cases are identical.

Once again, you are quite simply wrong, your mental model of how the DNS
is supposed to work is flawed.   You CANNOT assume anything from name
similarity - more checks of the DNS are required to determine where
the zone cuts exist.  If this isn't clear from 1034/1035/2181 then we
need to write something else to make it clear.

  | As far as DNS clients are concerned, munnari.oz.au has two address records,
  | 128.250.1.21 and 128.250.22.2. The information from rip.psg.com is an
  | attempt at cache poisoning.

No, poisoning is a loaded word and implies facts not in evidence - it is
(probably would be) an attempt to make caching as effective as it was
intended to be.   That is, to always make available any information that
had ben received previously (within the TTL).   That can be used for poisoning
or it can just be increasing the effeciency of the DNS.   Most clients
prefer speed and probable accuracy over higher reliability and excess
overheads.   The rules in 2181 that you were asking about are there to
help increase the likelihood of the accuracy of the answers, without undue
sacrifice of the effeciency of the global caching.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Dec 1999 07:32:30 -0000

> Because in the absence of signed data it trues the cache.

Incorrect records are still incorrect even if they are confined to the
additional section of the cache's responses.

How often does your cache provide false information? How often do these
``credibility'' rules stop your cache from providing false information?

Does your cache accept records other than ....x.dom from the x.dom NSes?
Do you have any real examples where the ``credibility'' rules caught a
false record that was _inside_ x.dom? Is there any reason to believe
that these mistakes are a noticeable fraction of all x.dom NS mistakes?

The whole ``credibility'' idea appears to predate serious anti-poisoning
rules such as enforcing x.dom NS limits. I've seen many real cases where
NS limits eliminated problems that wouldn't have been stopped, and often
wouldn't have been affected at all, by these ``credibility'' rules. When
I ask for evidence that the ``credibility'' rules aren't obsolete, all I
get are ancient examples that would never have happened with NS limits.

---Dan

---

From: Robert Elz <[email-masked]>
Date: Sun, 19 Dec 1999 17:48:31 +1100

Date:        17 Dec 1999 07:32:30 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The whole ``credibility'' idea appears to predate serious anti-poisoning
  | rules such as enforcing x.dom NS limits.

Where are those "rules" supposed to come from, and what exactly are
they supposed to be?

I fail to see why it is supposed to make a difference to anyone if (say)
munnari.oz.au should give a bogus A record (or MX or anything else) in
additional data for cy.yp.to when answering with the NS list for yp.to
(munnari is a server for .TO so it will get to give out that list), than
if it gives out a bogus answer for any other data.  Munnari isn't a NS for
yp.to so I can't even imagine where anyone would get the idea that just
because it happens to be a server for TO means it has any more credibility
for data in yp.to than any other random server on the net.

The "ancient examples that would never have happened with NS limits" are still
current examples, because there are no "NS limits" that anyone has yet
worked out how to rationally apply and do any better.

The only genuine anti-poising rules will be when servers start verifying SIG
records - once that happens, nothing else will matter.

kre