[dns-operations] Concerns regarding the ICANN/IANA DNS vulnerability checker

[Paul Vixie]

> [bd].ext.nic.fr (fr secondary servers operated by ISC) and others do
> not have the same behavior as a.nic.fr

this is because running recursive and authoritative service in the same
server image answering from the same IP address is not well supported by
the DNS specification, and while BIND is willing to do this for historical
reasons, ISC is not willing to live with the "guesses" BIND has to make
when configured for both authoritative and recursive.

> This proves that other TLD servers behave in another way.

it also proves that BIND should issue strong warnings to stderr and syslog
whenever someone turns on recursive service when they have any non-stub zones
defined.  we're just not getting the word out about how ugly this is.

> So my understanding is that serving A/AAAA in the additional section
> could help optimize the iterative queries down to the authoritative
> servers, and that's why it seems to be a widely spread configuration
> choice.

out-of-baliwick glue is ignored on the recipient's side, so this
configuration isn't doing anybody any good.  NOTE: thanks to kaminsky's
recent work we're likely going to have to give up on in-baliwick glue as
well.

> Is that considered a bad idea?
> 
> Please justify whether the answer is YES or NO.

YES.

> If the answer is "YES", may/should/must that behavior be disabled/stopped
> by simply configuring the server not to answer from cache, by setting for
> example "allow-query-cache { none; };" a la BIND 9.4/9.5+ ?

just use "recursion no;" and make sure there's no hint zone for ".".


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