On 26/03/14 10:37 AM, Nicholas Weaver wrote: > > On Mar 26, 2014, at 5:27 AM, Simon Kelley <[email protected]> wrote: > >> Signed PGP part >> On 25/03/14 23:03, Alex Xu wrote: >> >>>> >>> >>> Poor wording on my part. I meant that `dig isc.org @74.82.42.42 >>> +dnssec` returns no results, but `dig isc.org rrsig @74.82.42.42` >>> does. >>> >> >> That's no good as an upstream server: you need the RRSIGs in the >> answer, which is what a DNS server with DNSSEC support does. >> (Otherwise, every query which got an answer without RRSIGS would need >> another query to see if they exist or not, that would be very slow.)# > > Also, that fallback itself doesn't actually work on a lot of resolvers! > (Notably OpenDNS, but also the server Alex Xu is using) E.g: > >> dig RRSIG com @74.82.42.42 > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9312 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;com. IN RRSIG > > ;; ANSWER SECTION: > com. 86400 IN RRSIG DNSKEY 8 1 {crypto-goop} > com. 86400 IN RRSIG NS 8 1 {crypto-goop} > com. 900 IN RRSIG SOA 8 1 {crypto-goop} > com. 86400 IN RRSIG NSEC3PARAM 8 1 {crypto-goop} > > > Notably absent is the RRSIG for the DS for com, without which you can't > actually validate all that data. Bind does properly also include the DS > record (this is our local bind copy) > >> dig RRSIG com @192.150.186.8 > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.8.3-P1 <<>> RRSIG com @192.150.186.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10620 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 13, ADDITIONAL: 15 > > ;; QUESTION SECTION: > ;com. IN RRSIG > > ;; ANSWER SECTION: > com. 172756 IN RRSIG NS 8 1 {crypto-goop} > com. 86356 IN RRSIG NSEC3PARAM 8 1 {crypto-goop} > com. 86356 IN RRSIG DNSKEY 8 1 {crypto-goop} > com. 856 IN RRSIG SOA 8 1 {crypto-goop} > com. 26324 IN RRSIG DS 8 1 {crypto-goop} > > > Overall, my thought is "try to get RRSIG records from the recursive resolver" > is not a happy fallback: the number of cases where this work is actually > pretty small, since a resolver which properly includes the DS record is going > to support the request for DNSSEC records. > > Especially for the NAT case, the far better fallback is do an iterative > fetch, starting with the root and working down, when the recursive resolver > is noncooperative. >
I don't think this is a good idea. Dnsmasq is supposed to be a simple cache and lightweight; it defeats the purpose of dnsmasq to have it do recursive resolution. I don't know what response type would be appropriate here. Probably SERVFAIL with a message sent to syslog.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dnsmasq-discuss mailing list [email protected] http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
