fantuz / dnsproxy Goto Github PK

this print() shall be made so there is one less line

reasons:

• few bytes saved
• nicer
• extra pain in dnsp.c to handle such sequence of \r\n\t

esay to sove, WIP.

at least few formats and classes to break down:

• HTTP2 and DOH only
• robust multi standard clients (DNSP with his PHP or GO resolver)
• non standard HTTP DNS: dns.google.com to mention one

Goal is to discover more of this public service types, in order to build few pools.

this post to track the progress of "Hex signed 2's complement" rework.

TTL value is generated from headers, but not reflected correctly in UDP packet due to wrong conversion HEX to HEX 2's.

Tracking to find help and close soon, is trivial to fix.

DNSP and caching have a very tight relation.
If caching doesn't happen, DNSP can still go through proxy and get the desired response.
Problem is, the whole process without cache is bit slower (~100 msec per request depending on remote server's presence on the internet. It means, DNS response can get up to 200 msec per request.

Itself is not an issue, but I must have messed up with Etag and other caching headers, and I can get no cache anymore on my webserver, which happens to be behind CloudFlare caching/acceleration.

Caching was OK, it has always been working on simple Apaches/NGINX.
I want and need to repair it. Having the resource correcly cached means that we do not even need to get the 304 from the remote server, we shall pop the resource from the cache, but query string sometimes doesn't play nicely with Polipo or Squid......

DNSP doesn't seem to be impacted in its core functions, and the PHP is still fast, correct, looks good.
The problem is with cache-valdity overrides done by custom CloudFlare headers. Is a common practice for CDN, but it doesn't integrate with DNSP.

Solution: strip down the headers in the dnsp.c code programmatically, and fine tune HTTP cache to accept the suggested validity (14400).

Unfortunately, more work is due with regards to TCP size calculations and stamping.
A new algorithm is needed to predict size and dynamically change "window" value.
Issue affects only TCP listeners.

HI.

yudeMacBook-Air:DNSProxy-by-fantuz brite$ make
gcc -w -c dnsp.c
gcc dnsp.o -O2 -Wall -W -pedantic -g -rdynamic -DTLS -L/usr/local/lib -lcurl -lpthread -lrt -w -o dnsp
ld: library not found for -lrt
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [dnsp] Error 1
yudeMacBook-Air:DNSProxy-by-fantuz brite$

how to fix it? tks

As I was bit lazy, I forgot to add the TTL override setting...
my bad !

to summarize, i am creating this issue to track the TTL handling between DNS and HTTP responses.

So far we offer a static TTL although we could (should) return the TTL value to be reflected in the generated HTTP response.

easy-peasy (10-20 minutes), this issue is just a tracker, wip wip wip