DNS format error

[Tony Finch]

Yang Yu <yang.yu.list at gmail.com> wrote:
>
> the query error log can be replicated with "dig www.vip.icann.org ds"
> This sounds like a DNSSEC validation issue, but why would I get DNS
> format error in the log

This is weird and interesting.

The name servers for vip.icann.org are doing some kind of minimal covering
NSEC3 records in their responses with varying salt. They are somewhat
problematic because they are incompatible with negative answer synthesis,
e.g. if you query for a nonexistent RRtype at the zone apex, you get an
answer that asserts there are no records at that name.

$ dig +dnssec +norec @gtm1.mdr.icann.org. vip.icann.org txt | grep 'IN NSEC3'
vcv1gvphnmjemfjiljmfjgolg02det3g.vip.icann.org.	60 IN NSEC3 1 0 1 3EACB33008A7EEA0 VCV1GVPHNMJEMFJILJMFJGOLG02DET3H
$ NSEC3 1 0 1 3EACB33008A7EEA0 vip.icann.org
VCV1GVPHNMJEMFJILJMFJGOLG02DET3G (salt=3EACB33008A7EEA0, hash=1, iterations=1)

The servers seem to have special handling for certain RRtypes. If you ask
for QTYPE=NSEC3 you get a completely empty answer, which does not conform
to RFC 5155 section 7.2.3.

QTYPE=DS responses are also weird. The response is always just an empty
NSEC3 record for the zone apex (like the one above) and its RRSIG(NSEC3).
The NSEC3 owner does not match the QNAME unless you happen to query for
the apex.

$ dig -6 +dnssec +norec +noall +authority @gtm1.mdr.icann.org. stoat.vip.icann.org ds
vcv1gvphnmjemfjiljmfjgolg02det3g.vip.icann.org.	3600 IN	NSEC3 1 0 1 3EACB33008A7EEA0 VCV1GVPHNMJEMFJILJMFJGOLG02DET3H
vcv1gvphnmjemfjiljmfjgolg02det3g.vip.icann.org.	3600 IN	RRSIG NSEC3 7 4 3600 20150804183901 20150728183901 58127 vip.icann.org. MmXIg6proQwTw6tVt2wDea08lHbjsqf/BoMZZq7pNVyCLzwCyvjZP4HF zNNYv030e4uapd9DGwgjqNwDRaGU3WZg06WOxn7u3yVMqagSV9t4VAB1 nl0SZpYamV2TV/ZcBehmGTrdWh9Ei2pmlqyffvcq+4tQfcVeX7RDljHw u4U=
$ NSEC3 1 0 1 3EACB33008A7EEA0 stoat.vip.icann.org
JV27TTDI7M980OBC023FH646I4CE2352 (salt=3EACB33008A7EEA0, hash=1, iterations=1)

However the weirdness in the NSEC3 record is not what is upsetting BIND,
and it might be a bug. A noerror response with just NSEC3 and RRSIG(NSEC3)
in the authority section should (I think) be treated as a type 3 nodata
response (see RFC 2308). However BIND requires type 3 nodata responses to
have completely empty authority sections. BIND will only recognise type 1
or type 2 nodata responses (with SOA records in the authority section)
from signed zones.

Of course, if BIND accepted this answer as negative, it would fail
validation due to the NSEC3 owner mismatch.

ps. this is the NSEC3 command I used above because the mapping from NSEC3
RDATA to nsec3hash arguments is utterly confusing.

#!/bin/sh
# NSEC3 wrapper around nsec3hash
algo=$1
flags=$2
iters=$3
salt=$4
domain=$5
nsec3hash $salt $algo $iters $domain

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
South Utsire, Forties, Cromarty, Forth, Tyne: Northerly or northwesterly 5 to
7, perhaps gale 8 later in Forties. Slight or moderate, becoming moderate or
rough, occasionally very rough in Forties. Rain or showers. Good, occasionally
moderate.