Evan Hunt <e...@isc.org> wrote: > > This could be a pretty brilliant solution, actually: If you're > authoritative for a signed zone and you receive a query of type ANY, > return the applicable NSEC/NSEC3; if the zone is *not* signed, synthesize > a response containing a single RR with a type from the "private use" range > (e.g. TYPE65531 or whatever), zero length rdata, and a long TTL. The > resolver would get an answer, so it stops asking; it would *not* cache > the answer as an empty node, so subsequent queries for other qtypes can > still resolve.
I tried this and it works OK. In the below, > is an nsupdate prompt and $ is a shell prompt in another window. # set up fake ANY response > add bar.mini.dotat.at 60 in type6666 \# 1 66 > send # cache fake ANY response $ dig +short bar.mini.dotat.at any \# 1 66 # set up real response > del bar.mini.dotat.at > add bar.mini.dotat.at 60 in txt "booze" > send # name server fetches missing RRsets $ dig +short bar.mini.dotat.at txt "booze" > I like this better than any of the prior suggestions. (It doesn't > address qmail's problem, but that's a lost cause no matter which method > is chosen.) This will work with qmail. Its query sequence is: ANY (for CNAME-based rewriting and to prime the cache); MX (for delivery); fallback to A. With this proposal, it will get a no-CNAME reply to ANY, so it will not rewrite the address. Then it will get the same answers as before to its MX etc. queries. The delivery will proceed OK. Slightly interesting things occur if there is actually a CNAME at the query name, but this is the same as what would happen if you are lucky enough to make these queries while the QNAME changes from not-a-CNAME to actually-a-CNAME. So it is OK to always give a fake reply to an ANY query. If you are feeling generous when you implement this idea, you can add a special case when the QNAME is a CNAME and return that, which will preserve qmail's rewriting behaviour. When you have cached non-CNAME data at a name and a subsequent query gets a CNAME answer, the CNAME overrides the existing data at that name if you make more not-ANY queries. But you can get some, um, interesting responses to ANY queries. ; <<>> DiG 9.11.0pre-alpha <<>> bar.mini.dotat.at any ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54981 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;bar.mini.dotat.at. IN ANY ;; ANSWER SECTION: bar.mini.dotat.at. 3596 IN CNAME localhost. bar.mini.dotat.at. 3578 IN TXT "booze" ;; AUTHORITY SECTION: mini.dotat.at. 86400 IN NS mini.dotat.at. ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Mar 13 11:00:27 GMT 2015 ;; MSG SIZE rcvd: 101 Tony. -- f.anthony.n.finch <d...@dotat.at> http://dotat.at/ Viking, North Utsire: Southerly 6 to gale 8, decreasing 4 or 5. Rough or very rough, becoming moderate or rough. Fair. Good. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
