Re: [dev] Suckless DNS server
Hello, folks, Authoritative suckless DNS server recommendations please! Thanking you Sagar Acharya https://humaaraartha.in 20 Jul 2023, 10:32 by minsh...@umich.edu: >> I meant `ntohs`... and this further proves your point. >> Thank you for your insight & for the article. >> > > +1 ! >
Re: [dev] Suckless DNS server
> I meant `ntohs`... and this further proves your point. > Thank you for your insight & for the article. +1 !
Re: [dev] Suckless DNS server
On 07/20/23 04:57AM, NRK wrote: > > C standard defines shift operator as multiplication and division by > powers of 2. And the result of `x * 256` never depend on the system's > byte order and so neither does `x << 8`. > > Rob Pike already has an excellent article on this, so I'll just refer to > that: https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html > I now realize that I was not right. You're correct. > > Instead, one can use htons(byteorder.3). > > If anything, those functions are precisely the source of confusion like > these and should be avoided for this reason. > I meant `ntohs`... and this further proves your point. Thank you for your insight & for the article. Jeremy
Re: [dev] Suckless DNS server
On Wed, Jul 19, 2023 at 03:20:21PM -0700, Jeremy wrote: > crypto_uint16 uint16_unpack_big(const unsigned char *x) > crypto_uint16 y; > > y = x[0]; y <<= 8; > y |= x[1]; > > return y; > } > > As you're probably already aware, if there were 3 answers, and you > were running this on a Big Endian machine, the program would attempt to > iterate over 768 answers. I fail to see how that'd happen. The above routine takes a 16bit big endian encoded byte stream and places the bytes into the right place *regardless* of what the host system's byte order is. C standard defines shift operator as multiplication and division by powers of 2. And the result of `x * 256` never depend on the system's byte order and so neither does `x << 8`. Rob Pike already has an excellent article on this, so I'll just refer to that: https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html (Though keep in mind that the shift of 24 needs to be casted to unsigned - i.e `(unsigned)data[3]<<24` - to avoid UB due to the result being bigger than `INT_MAX`). > Instead, one can use htons(byteorder.3). If anything, those functions are precisely the source of confusion like these and should be avoided for this reason. As already explained in Rob's article above, the host system's byte order is almost never relevant, what matters is what byte order is the data stream encoded in. As long as you know that, you can simply shift the bytes into proper place *never* needing to ask or know about the host system's byte order. - NRK
Re: [dev] Suckless DNS server
On 07/20/23 12:09AM, NRK wrote:
> FYI I'm not exactly interested in defending dq because I know nothing
> about it, but the above criticism at least seems more like knee jerk
> reaction due to something being different rather than actual/technical
> criticism.
>
> - NRK
>
Thanks for your response. Though it was a knee-jerk response, in my
experience, reimplementing libc(being different) without acknowledging
it is pretty effective heuristic for spotting non-portable code.
For example, in the ip_packet function, the author writes:
numanswers = uint16_unpack_big(data + 6);
...
while (numanswers--) {
...
}
The uint16_unpack_big definition:
crypto_uint16 uint16_unpack_big(const unsigned char *x)
crypto_uint16 y;
y = x[0]; y <<= 8;
y |= x[1];
return y;
}
As you're probably already aware, if there were 3 answers, and you
were running this on a Big Endian machine, the program would attempt to
iterate over 768 answers. Instead, one can use htons(byteorder.3).
That may be another knee-jerk criticism, but I have trouble seeing any
point looking further.
Jeremy
Re: [dev] Suckless DNS server
> const char *e_str(int i)
> {
> X(0,"no error");
> X(EINTR,"interrupted system call")
> X(ENOMEM,"out of memory")
> X(ENOENT,"file does not exist")
> X(ETXTBSY,"text busy")
> X(EIO,"input/output error")
> ...
> return "unknown error";
> }
>
> Maybe this is just comedy?
The real comedy is strerror() not being thread-safe because on certain
implementation it returns a static buffer:
https://man.freebsd.org/cgi/man.cgi?query=strerror=0#end
> void byte_copy(void *yv, long long ylen, const void *xv) {
>
> long long i;
> const char *x = xv;
> char *y = yv;
>
> for (i = 0; i < ylen; ++i) y[i] = x[i];
> }
>
> Of course, byte_copy is superior to memcpy & strncpy here because he's
> copying some pretty long(!) strings.
I do no know what the purpose of this was, but interface wise, it is
indeed superior to memcpy because it can deal with
`n == 0 && (src == NULL || dst == NULL)` case without invoking UB:
https://port70.net/~nsz/c/c99/n1256.html#7.21.1p2
| n can have the value zero [but] pointer arguments on such a call shall
| still have valid values
And in practice, compilers like to mark any arguments to string.h
functions as non-null unconditionally due to the above reason.
https://godbolt.org/z/brz7jhchr
---
FYI I'm not exactly interested in defending dq because I know nothing
about it, but the above criticism at least seems more like knee jerk
reaction due to something being different rather than actual/technical
criticism.
- NRK
Re: [dev] Suckless DNS server
On 07/19/23 04:20PM, Sergey Matveev wrote:
> >Which DNS server do you recommend to use?
>
> https://github.com/janmojzis/dq is pretty lightweight and simple.
I respect the endeavour but this author seems to dine pretty heavy on
thick paint chips. Before returning from strtoip4, he does the following:
int strtoip4(unsigned char *ip, const char *x)
...
byte_copy(ip, 12, "\0\0\0\0\0\0\0\0\0\0\377\377");
return 1;
}
And here is byte_copy:
void byte_copy(void *yv, long long ylen, const void *xv) {
long long i;
const char *x = xv;
char *y = yv;
for (i = 0; i < ylen; ++i) y[i] = x[i];
}
Of course, byte_copy is superior to memcpy & strncpy here because he's
copying some pretty long(!) strings.
Also, your binary IPv4 address buffer needs to be at 16-bytes long so
the author can populate the first 12-bytes with a mysterious string literal.
Another excerpt:
#define X(e,s) if (i == e) return s;
const char *e_str(int i)
{
X(0,"no error");
X(EINTR,"interrupted system call")
X(ENOMEM,"out of memory")
X(ENOENT,"file does not exist")
X(ETXTBSY,"text busy")
X(EIO,"input/output error")
...
return "unknown error";
}
Maybe this is just comedy?
In all seriousness, this project seems moreso exploratory than lightweight
& simple. Either that or I do not understand the author's objectives here.
Jeremy
Re: [dev] Suckless DNS server
Please let us know authoritative and recursive DNS servers. Thanking you Sagar Acharya https://humaaraartha.in 19 Jul 2023, 18:50 by stargrave+suckl...@stargrave.org: > *** Sagar Acharya [2023-07-19 15:08]: > >Which DNS server do you recommend to use? > > https://github.com/janmojzis/dq is pretty lightweight and simple. > It is based on DJB's https://cr.yp.to/djbdns.html, but supports IPv6 and > most importantly DNSCurve, that does not rely on single trust anchor and > just does not suck: > https://dnscurve.io/faq/differences-between-dnscurve-and-dnssec.html > > However personally I also like https://nlnetlabs.nl/projects/unbound/about/ > that is used by default in FreeBSD and OpenBSD, being relatively > lightweight too. It has built-in DNSCrypt (if you desire it), full > cached DNSSEC support and DNS64. > > -- > Sergey Matveev (http://www.stargrave.org/) > OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A >
Re: [dev] Suckless DNS server
*** Sagar Acharya [2023-07-19 15:08]: >Which DNS server do you recommend to use? https://github.com/janmojzis/dq is pretty lightweight and simple. It is based on DJB's https://cr.yp.to/djbdns.html, but supports IPv6 and most importantly DNSCurve, that does not rely on single trust anchor and just does not suck: https://dnscurve.io/faq/differences-between-dnscurve-and-dnssec.html However personally I also like https://nlnetlabs.nl/projects/unbound/about/ that is used by default in FreeBSD and OpenBSD, being relatively lightweight too. It has built-in DNSCrypt (if you desire it), full cached DNSSEC support and DNS64. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: 12AD 3268 9C66 0D42 6967 FD75 CB82 0563 2107 AD8A
[dev] Suckless DNS server
Which DNS server do you recommend to use? I use pdns, I think a DNS server can be a thing which merely resolves a string and cryptography for encryption, namely DNSSEC. Comments around the concepts are welcome. Thanking you Sagar Acharya https://humaaraartha.in
