[dns-operations] How many kinds of DNS DoS attacks are we trying to stop ?

Phil Pennock dnsop+phil at spodhuis.org
Fri Sep 28 20:45:31 UTC 2012

On 2012-09-28 at 10:00 +0100, Tony Finch wrote:
> I don't understand what bailiwicks or glue records have to do with MX targets.

This one part of the phrasing has been blown out of proportion.

I'll explain exactly what I meant, using phrasing which is probably
patronising to someone of your skill level, so that you can see that I
understand too.

A paranoid resolver ignores ADDITIONAL records that are not in
bailiwick, does not know anything about zone cuts which happen between
the ANSWER and ADDITIONAL, so modern servers don't bother returning
entries in ADDITIONAL unless they're in bailiwick; I was using
"in-bailiwick" as an adjective to describe the additional answers which
aren't glue or the like, just saying "well, they're gone".

That's all it was.

> > > Clients are allowed to assume that records are not dropped from the middle
> > > of truncated responses, because that is forbidden by section 6.2 of RFC
> > > 1035.
> >
> > And yet some do, which is why Bind is stricter than the RFC requires it
> > to be and will only truncate at the end.
> No I think it is exactly as strict as the RFC requires. If anything there
> is a bug in the EDNS spec since it doesn't explicitly amend the truncation
> rules to allow records to be dropped from preceding sections.

This one is my fault and was a parse error on my part; sorry.  I missed
the "not" from your assertion and was very confused by its strangeness.
Rather than assert false statements, I stuck to describing what actually
happens, based on what I understood you to describe from the RFC instead
of going back and checking it myself.  My laziness bit me.

We're actually in agreement here; the difference is I wrote "some
clients" without stating "any client may, some clients actually do".  I
forget which code base I saw which, on getting a TC, just grabbed
everything from the TCP query irregardless of section: more thorough
than the RFC requires it to be.


More information about the dns-operations mailing list