Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
Thanks to all for your help. I figured out what the problem was (apparently, the RFCs not withstanding), several major DNS servers, including bind, treat 'meta' RRTYPEs (128-255) as special, namely, they will NOT process them or pass them, instead giving various errors. The test now uses a non-meta RRTYPE (type 1169). Oh, and I found out how to get dig to do arbittrary rtypes: dig type1169 txt.netalyzr.icsi.berkeley.edu
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
No worries, those queries will be useful enough. THanks! On Tue, Nov 30, 2010 at 2:11 PM, Simon Kelley wrote: > On 30/11/10 20:15, Nicholas Weaver wrote: >> >> Thanks all, this helps a lot! >> >> A related question: The chaos txt version.bind query is very useful, >> but is there a similar query to get the DNS server(s) that Dnsmasq is >> forwarding to? >> > > > Sorry, no. The available queries are > > version.bind > authors.bind > copyright.bind > > Something could be added, but it would take a long time to get out to the > installed base of cheap plastic routers. > > Simon. >
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
On 30/11/10 20:15, Nicholas Weaver wrote: Thanks all, this helps a lot! A related question: The chaos txt version.bind query is very useful, but is there a similar query to get the DNS server(s) that Dnsmasq is forwarding to? Sorry, no. The available queries are version.bind authors.bind copyright.bind Something could be added, but it would take a long time to get out to the installed base of cheap plastic routers. Simon.
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
Thanks all, this helps a lot! A related question: The chaos txt version.bind query is very useful, but is there a similar query to get the DNS server(s) that Dnsmasq is forwarding to?
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
On 30/11/10 19:49, Jan Seiffert wrote: I would also guess it's not only a problem of broken dns proxys, but also "cleaning" provider server. dnsmasq is fine. From an dnsmasq 2.52 with it's own powerdns recurser, i get all green lights (OK, besides that i filter ad.doubleklick.net, but who wants to talk to _them_, anyway). Yes, that seems to be the case. My ISPs DNS servers return a NOTIMP RCODE for the RTYPE=169 query. ISP is Viginmedia in the UK. Simon.
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
2010/11/29 Simon Kelley : > On 29/11/10 19:30, Nicholas Weaver wrote: > >> RFC3597 specifically states how they should be handled (as opaque >> binary data which is passed unchanged), but almost all fail to process >> our request for a made-up type (type # 169). >> >> a) Could someone run Netalyzr against a NAT running the latest >> Dnsmasq code and send me the result link? > > OK, I just did this, and got the error. > > Your NAT has a built-in DNS proxy. We sent it a DNS request and our > server received it from 62.253.128.100. > Some or all specialized DNS types checked are not properly interpreted > by the NAT's DNS proxy. The following tested queries were blocked/failed: > > * RTYPE=169 (deliberately unknown) records. > > > 62.253.128.100 is cmbg-dnsany-1.server.virginmedia.net. which makes > sense, as my ISP is viginmedia. I'm very sure that a query for RTYPE=169 > will have been forwarded Ok by dnsmasq, so maybe the problem is at the > ISP end? > I would also guess it's not only a problem of broken dns proxys, but also "cleaning" provider server. dnsmasq is fine. From an dnsmasq 2.52 with it's own powerdns recurser, i get all green lights (OK, besides that i filter ad.doubleklick.net, but who wants to talk to _them_, anyway). [snip] > > Cheers, > > Simon. > > Greetings Jan -- Murphy's Law of Combat Rule #3: "Never forget that your weapon was manufactured by the lowest bidder"
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
Here are results from my system: http://n3.netalyzr.icsi.berkeley.edu/summary/id=ae81b058-4485-88b87afa-9e91-46b0-90a7#feedback I have port 53 blocked for TCP output. If I should unlock it for some reasons - please tell me. dnsmasq-2.56test17 / no-IPv6 -- jasiu
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
Oh wait, no it didn't pass... We dump what we do to stdout and upload it at the transcript: http://netalyzr.icsi.berkeley.edu/transcript/id=43ca208a-28815-3a04eee7-dbda-4220-84b4/side=client The test in question is #31. (I was looking at the wrong test, we also test the same name directly to our server to check for in-path filtering)
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
Thanks! Yeah, the ID is very useful (we can use that to get information from specific sessions) Unfortunately I don't know how to coerce dig into using unknown query types (its a custom written DNS library in Java that we use, RTYPE=169 is the rtype # we use, and the data format is that of a txt record). The server identification makes sense, because what it does is it queries for a special name (server.netalyzr.icsi.berkeley.edu) which returns the IP address where the request eventually came from, so the path was Applet -> NAT -> (ISP) -> Authority. Which is the IP which the server's requset comes from (often these ISP dns servers are clutery-beasts which will issue the outbound request through). Although F-me, the transcript looks like it passed, but the display doesn't, so I think this may be a rendering bug?!? On Mon, Nov 29, 2010 at 12:57 PM, Simon Kelley wrote: > On 29/11/10 19:30, Nicholas Weaver wrote: > >> RFC3597 specifically states how they should be handled (as opaque >> binary data which is passed unchanged), but almost all fail to process >> our request for a made-up type (type # 169). >> >> a) Could someone run Netalyzr against a NAT running the latest >> Dnsmasq code and send me the result link? > > OK, I just did this, and got the error. > > Your NAT has a built-in DNS proxy. We sent it a DNS request and our server > received it from 62.253.128.100. > Some or all specialized DNS types checked are not properly interpreted by > the NAT's DNS proxy. The following tested queries were blocked/failed: > > * RTYPE=169 (deliberately unknown) records. > > > 62.253.128.100 is cmbg-dnsany-1.server.virginmedia.net. which makes sense, > as my ISP is viginmedia. I'm very sure that a query for RTYPE=169 will have > been forwarded Ok by dnsmasq, so maybe the problem is at the ISP end? > > Is there a command line tool that will generate these queries simply? dig > only sends queries whose name it knows. > > The ID of the netalyzer run was 43ca208a-28815-3a04eee7-dbda-4220-84b4 if > that's useful. > > > Cheers, > > Simon. > > >
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
On 29/11/10 19:30, Nicholas Weaver wrote: RFC3597 specifically states how they should be handled (as opaque binary data which is passed unchanged), but almost all fail to process our request for a made-up type (type # 169). a) Could someone run Netalyzr against a NAT running the latest Dnsmasq code and send me the result link? OK, I just did this, and got the error. Your NAT has a built-in DNS proxy. We sent it a DNS request and our server received it from 62.253.128.100. Some or all specialized DNS types checked are not properly interpreted by the NAT's DNS proxy. The following tested queries were blocked/failed: * RTYPE=169 (deliberately unknown) records. 62.253.128.100 is cmbg-dnsany-1.server.virginmedia.net. which makes sense, as my ISP is viginmedia. I'm very sure that a query for RTYPE=169 will have been forwarded Ok by dnsmasq, so maybe the problem is at the ISP end? Is there a command line tool that will generate these queries simply? dig only sends queries whose name it knows. The ID of the netalyzer run was 43ca208a-28815-3a04eee7-dbda-4220-84b4 if that's useful. Cheers, Simon.
Re: [Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
On 29/11/10 19:30, Nicholas Weaver wrote: I'm one of the primary authors of Netalyzr ( http://netalyzr.icsi.berkeley.edu ). One problem we test for that we see as absolutely endemic (>95% of the cases tested) is NAT DNS proxies that can't handle unknown DNS resource records. RFC3597 specifically states how they should be handled (as opaque binary data which is passed unchanged), but almost all fail to process our request for a made-up type (type # 169). a) Could someone run Netalyzr against a NAT running the latest Dnsmasq code and send me the result link? Under those circumstances, dnsmasq forwards the query bit-for-bit with the exception of the query-id and similarly relays the reply bit-for-bit to the original requestor. b) Are there various bugs/queries which can be done which would indicate what version of Dnsmasq a gateway is running? It supports the standard TXT/CHAOS records in the .bind domain that BIND does: srk@archie:~$ dig chaos txt version.bind ; <<>> DiG 9.7.0-P1 <<>> chaos txt version.bind ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38004 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "dnsmasq-2.55" ;; Query time: 4 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Mon Nov 29 20:25:55 2010 ;; MSG SIZE rcvd: 61 HTH Simon.
[Dnsmasq-discuss] Handling unknown RTYPEs and querying for version...
I'm one of the primary authors of Netalyzr ( http://netalyzr.icsi.berkeley.edu ). One problem we test for that we see as absolutely endemic (>95% of the cases tested) is NAT DNS proxies that can't handle unknown DNS resource records. RFC3597 specifically states how they should be handled (as opaque binary data which is passed unchanged), but almost all fail to process our request for a made-up type (type # 169). a) Could someone run Netalyzr against a NAT running the latest Dnsmasq code and send me the result link? b) Are there various bugs/queries which can be done which would indicate what version of Dnsmasq a gateway is running?
