* Stephane Bortzmeyer:
It is highly improbable that all these name servers are unreachable
from you. Therefore, I suspect that *content* is the issue. RIPE-NCC
zones are signed with DNSSEC. Are you sure you do not have a broken
middlebox which deletes DNSSEC-signed answers?
Ahem. dig's +trace doesn't use EDNS by default, so no signatures and
(usually) no large responses.
For extra realism, you need to add +dnssec +norecurse, and +all for
usefulness.
I don't see the point you are trying to make in this discussion.
I can see that. I don't have a clue bat big enough for the task.
Are
you saying
Troll skat.
I'm out.
I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4.
drugs# foreach h ( SUNIC.SUNET.SE TINNIE.ARIN.NET NS-PRI.RIPE.NET NS3.NIC.FR SEC3.APNIC.NET SEC1.APNIC.NET SNS-PB.ISC.ORG )
foreach? echo $h `dig +short $h aaaa`
foreach? end
SUNIC.SUNET.SE 2001:6b0:7::2
TINNIE.ARIN.NET 2001:500:13::c7d4:35
NS-PRI.RIPE.NET 2001:610:240:0:53::3
NS3.NIC.FR 2001:660:3006:1::1:1
SEC3.APNIC.NET 2001:dc0:1:0:4777::140
SEC1.APNIC.NET 2001:dc0:2001:a:4608::59
SNS-PB.ISC.ORG 2001:500:2e::1
drugs#
Mark
> * Stephane Bortzmeyer:
>
> > It is highly improbable that all these name servers are unreachable
> > from you. Therefore, I suspect that *content* is the issue. RIPE-NCC
> > zones are signed with DNSSEC. Are you sure you do not have a broken
> > middlebox which deletes DNSSEC-signed answers?
>
> Ahem. dig's +trace doesn't use EDNS by default, so no signatures and
> (usually) no large responses.I actually suspect no IPv6 path rather than DNSSEC, add a -4 to force IPv4.
drugs# foreach h ( SUNIC.SUNET.SE TINNIE.ARIN.NET NS-PRI.RIPE.NET NS3.NIC.FR
SEC3.APNIC.NET SEC1.APNIC.NET SNS-PB.ISC.ORG )
foreach? echo $h `dig +short $h aaaa`
foreach? end
SUNIC.SUNET.SE 2001:6b0:7::2
TINNIE.ARIN.NET 2001:500:13::c7d4:35
NS-PRI.RIPE.NET 2001:610:240:0:53::3
NS3.NIC.FR 2001:660:3006:1::1:1
SEC3.APNIC.NET 2001:dc0:1:0:4777::140
SEC1.APNIC.NET 2001:dc0:2001:a:4608::59
SNS-PB.ISC.ORG 2001:500:2e::1
drugs#
Also a more recent DiG than from BIND 9.3.3 would have helped. 
Nameservers that are not DNSSEC aware will not get responses that
contain DNSSEC records unless a client explicitly requests a DNSSEC
record type or make a * (ANY) request.
There is no problem to solve. Just a lot of misunderstanding.
That said the majority of nameservers on the planet are DNSSEC aware
and will request the DNSSEC record to be returned. They will also
fall back to plain DNS if middleware blocks the response.
Mark
As you've understood I need to read something extra about DNSSEC support.
The most things I know about DNSSEC are based on my contacts with software
writers that create nameservers and system administrators maintaining
multiple nameservers. So if I understand it correctly; if a resolver
requests DNSSEC information (together with for example www.domain.tld) and 1
resolver before the AUTH nameserver doesn't have DNSSEC it won't ask/require
DNSSEC? In that case men in the middle attacks are still possible. Also note
that a provider might have multiple resolvers with some using/able to
provide DNSSEC and others without DNSSEC support.
Mark
DNSSEC requires a DNSSEC clear path between the validator and the
authoritative servers. If there is not a DNSSEC clear path the
answers will be rejected as they cannot be validated. A man in the
middle can launch a denial of service attack but cannot launch a
spoofing attack.
Most validators, at the moment, are co-located with iterative
resolvers which provide the DNSSEC clear path. Some applications
are fully DNSSEC aware and do their own validation in which case
there needs to be a DNSSEC clear path to the recursive resolver and
onwards to the authoritative servers. Other applications are only
AD aware, in which case they trust the recursive resolver and need
channel security between the application and the recursive resolver.
Mark
I don't know if it's material as most DNS stuff is over my head, but
Geoff Houston has written about the in-addr.arpa situation in the most
recent edition of his Internet Society ISP Column
Mark Andrews wrote: