Yang Yu <yang.yu.l...@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 <d...@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. _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
