[dns-operations] anybody here from GDNS?

[Paul Vixie]

> Does this help?

nope.

> I assume any spoofing attack explanations at blackhat will start with
> "ways to make a remote host ask the queries you want to spoof answers
> to", since you can't (yet - maybe I'll learn differently in August)
> successfully spoof a recursive server that isn't recursing.

reasons not to run recursive and authoritative on the same server start with
the question of the shared node.  goes like this.  you're authoritative for
DEC.COM and you're recursive.  someone asks you for JOVE.PA.DEC.COM, RD=1,
and you have to iterate to go find it.  in the process, you learn an NS RRset
for PA.DEC.COM's apex that differs from the PA zone cut at DEC.COM's bottom.

thereafter, what will you answer if someone asks you for PA.DEC.COM NS?  if
you say, it depends on whether RD is 0 or 1, you'd be technically correct,
but you'd have to agree that no RFC specifies this, and you'd probably know
that no nameserver implements this.

extra credit -- someone asks you for ACETES.PA.DEC.COM and you have to go
ask the PA.DEC.COM nameservers to get it.  which NS RRset will you use -- is
it the one at the bottom of the DEC.COM zone you're authoritative for, or is
it the apex you learned while iterating earlier?  if you said "always use
the one you learned while iterating" you win a prize.  there are RFCs which
imply this, at least.  and there are nameservers which implement it.  huzzah.

anyone doing both authority and recursive in the same nameserver images
should be using views.  or multiple nameserver images, each having its own
listener IP.  note that in the case of views, the nameserver really does
ask itself questions and answer them.  in the case of multiple images, they
really do discover eachother by iterating downward from the root zone.

btw: these examples, like this problem itself, are 20 years old this week.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.