The Title says it all.
A Router that is newly on the market should at least be able to resolve its own hostname OUT OF THE BOX
Please update the available dnsmasq package to 2.76 instead of 2.73
This version supports dnssec and then get rid of that ******* knot.
Or give us a gui to configure the dnsnames in knot properly.
Or forward the dnsrequests not resolved by knot to dnsmasq on port, let’s say 5353
In case this is just a community forum and no developers step by.
Where can we post such bugs, so the devs see them?
There is only one DNS, the one on the Internet. If your router has it’s hostname in the DNS, then it’s resolvable out of the box. The main purpose of this device is to connect you to the Internet, to the proper DNS without any fake data. In this sense, local DNS zone can be even considered as a bad practice of faking DNS answers.
The DNSSEC support in dnsmasq is pretty basic, be sure there would be much more problems with it. Nevertheless, I’m pretty sure kresd will not get replaced.
This community forum is monitored by developers. You can always reach the developers on GitLab or GitHub.
But in this case, the fixup of local DNS resolution is already on it’s way, so it’s not necessary.
Connecting to internet is something, that many 20 EUR / 500 CZK devices can handle just fine. When getting 200 EUR device, I want more capabilities, than just connecting to internet.
Many people who purchase expensive routers, have a lot of devices at home. From NAS, smart TVs and players, A/C control, light control, etc. I, for example, would refuse to use any router, that would force me to remember the IP address of my NAS (especially the IPv6 one). That thing alone would get it instantly out of list of routers, considered for purchase. Therefore, local domains are an important part of the whole package.
Additionaly, sometimes it’s me who wants to fake the data of DNS responses. The typical use case is adblocking. Someone can say, that there are plugins for browsers, but that’s not the whole picture: a) the plugin in given browser can be castrated (compare Ghostery for Chrome and Firefox, the Chrome one has much less control over what it can block) b) the trend of increasing control over extensions, their API and whether they load at all (i.e. Firefox) and c) on some platforms you cannot have browser extensions at all (i.e. Chrome for Android). The fake DNS replies perfectly sidestep this problem.
You’ve got fully open-source router where you can do whatever you want. But still, connecting to the proper Internet is its basic feature.
There are certainly other solutions for this. One could be the multicast DNS, other could be using the proper public DNS for your home devices and never deal with the DNS split-brain again.
That is why you have an open-source driven router, where you can do whatever you want. But I would not agree that such functionality of faking DNS answers is considered a basic functionality that should be available out of the box.
Do you really want me to put local IPV4 Adresses to the dns of my bought domain-dns???
But how to do all that properly.
Others say it is bad practice to include local IPs in DNS
Unfortunately there is no IPV6 in Switzerland with SALT. At the moment. This is really horrible.
If I had IPV6 i would definitely go for it.
Is there an alternative?
As I already said, other alternative could be the mDNS, if supported by devices. If not, then you probably have to deploy a local DNS zone, which is possible by various ways already discussed in this forum (the simplest is just to wait until it gets fixed in some future update).
Just to make it clear: You are certainly free to deploy local DNS zone or whatever other DNS faking it in your own network. That is actually the point of having OSS-powered router. I just don’t like this generic idea that local DNS naming should be a basic feature that every router has to support and its absence is a major failure of the Turris project.
Even my, otherwise great ISP (Orange) does not think that DNSSEC is a basic part of the Internet (as in: it is not supported). In the test page in the basic Omnia UI, I had exactly two green items - the rest were red.
mDNS is local-link link only (i.e. over VPN, you will get nothing) and has dedicated domain (.local). Split-horizon DNS is used in most managed networks and is more fundamental part of IP networking, than DNSSEC ever was.
That article does not even start answering the points of the article that I linked. At minimum: a) it does not explain, how the security is increased, when all the layers in the stack above consider it unreliable and do their own verification (i.e. in TLS-based protocols, it is redundant and the only things it can produce are errors; in insecure protocols, where it could help you have bigger problems elsewhere anyway) b) it hand waves away the criticism of DANE (DANE is not a problem because DNS is government controlled anyway? Seriously, that’s supposed to an argument?) c) does not address the fact, that it’s crypto is obsolete (no, you can’t just claim that you will switch to other crypto later - who is going to upgrade all the devices? We are switching to IPv6 for 20 years already and you can see the result). d) basically, all the rest.
There are lots of broken networks out there. Most of them don’t even support IPv6. So what?
So is NAT. But neither technology is really part of the Internet (notice the capital I, not just a random internet but the Internet)
From the linked atricle:
Securing a lower level of the networking stack makes everything more secure.
…
Moxie Marlinspike and other researchers have proven that MITM attacks which simply downgrade to HTTP have a near 100% success rate. MITM attacks by exit nodes on Tor are common enough that Facebook and Blockchain.info have setup .onion URLS. A local DNSSEC validating resolvers would make most MITM attacks prohibitively expensive.
Another example would be the e-mail service. Without DNSSEC, there is no way for you how to make sure you are sending the mail to the proper destination. It relies solely on DNS and no, it does not consider it unreliable and doesn’t do any other verification.
DNS is goverment-controlled database. It always have been. Since anybody controlling the DNS can obtain a TLS certificate (see for instance Let’s Encrypt), the PKI is goverment-controlled as well. So DANE makes nothing worse, other than it lower mis-issue capabilities of CAs.
TLS also started as SSL with cryptos like RC4 or MD5.
It’s a big difference between using a 1024bit RSA for 10 years in a CA root certificate and using it for at most 3 months in DNSSEC. Plus, there have not been any practical exploits to 1024bit RSA yet and it’s already gone from the root zone. Lots of zones are already signed using EC-algorithms and more (even some TLDs) are soon to come.
may be you just have to understand, that different point of view is not BUG. You have just different point of view. Lot of threads here in forum are solving these points, may be better would be just to go through them.
