Re: Best practice for forwarding Dnstap (unix socket) traffic to another address
I should have included this in the first message, and I apologize. What I'm looking at is trying to build a BIND kernel, like a nanokernel. Socat won't work in this case, because because there's no "IPC" layer, because there is only one process in the kernel. One process. No users. I need to get data out of it into the network layer. -- Fred ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Best practice for forwarding Dnstap (unix socket) traffic to another address
Hello. For a variety reasons: * Dnstap doesn't comport with the usual MTU restrictions, that is an "event" is not reliably going to fit in a UDP frame. * Dnstap casts your application as the "server" and BIND as the "client". * For whatever reasons the implementer(s) saw fit to include a mandatory handshake (all it does it say "ok, I'm sending X, what do you want?" and you have to respond with whatever the client sent). * The only streaming that Dnstap has offered has been unix sockets. What's the best practice for sending this to another address, presumably via TCP... socat? Too bad about the handshake, any best practices for forwarding there? Thanks in advance... (Pure Python implementation of fstrm: https://github.com/m3047/shodohflo/blob/master/shodohflo/fstrm.py) -- Fred Morris, internet plumber and data sous chef ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?
FTR Jason has been warned before to stop sending this nonsense about Hidden Google Internet and I’ve put them on the moderation list for now. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 9. 1. 2022, at 12:58, Jason Vas Dias wrote: > > Thanks Fred - > > Though really all I am trying to do is ensure I can access > all public DNS names, which my experience shows me I > cannot, using my ISP's name-servers. > > It seems there is a Hidden Google Internet that I cannot access > unless I use Google's DNS servers, giving Google data > about me to sell - this is what I am trying to avoid . > > RE: >> Can't you do the auth lookups directly? Have you tried? > > You mean add topsectechnology.net's DNS servers to > my Forwarders list ? > > How do I find out what they are, when the domain > cannot be looked up by ICANN's WHOIS service ? > > And really this would not be a solution, every time I get an > NXDOMAIN error, I'd have to access multiple web-sites > to find the authoritative nameserver for the domain > (which fails for topsectechnology.net anyway), and > then add them to my Forwarders list ? > > Is this the way the DNS is meant to work these days ? > > I thought the DNS was meant to be public and global. > > I see that nowadays it is not . What a shame ! > How did we let this happen ? > > And this is meant to be a vital public information service ! > Why choose to hide the domain name that allows the public > to make a Covid Booster booking, unless the intent is > to exclude a section of society from accessing it ? > >> the BIND mailing list is were I should direct my ire. > >Isn't this the BIND mailing list we are discussing this on? >Is there another one I should be using ? If so, please let >me know . > >> Any response you get here is going to involve changing your >> BIND server's configuration and behavior, probably to convert >> it from forwarding to caching... > > Fine ! I am just using a slightly modified Red Hat > caching nameserver example named.conf, enclosed . > > Why isn't this a caching nameserver ? > > If anyone could suggest how to turn my config into one > that is able to query the Google Hidden Internet, without > accessing a Google Server, please let me know. > > Thanks & Best Regards, > Jason > >> On 08/01/2022, Fred Morris wrote: >> Wow. >> >> 1) You're using BIND as a caching nameserver. >> >> So you say. Does the nameserver do its own upstream (authoritative) >> lookups? If yes, then the term of art is "recursive / caching"; otherwise >> the term is "forwarding". >> >> Looks like you're configuring your ISP's nameservers as forwarders. >> Therefore the proper term is "forwarding". >> >> 2) Your ISP's nameservers fail to resolve $FQDN. >> >> These are other people's caching nameservers. >> >> 3) Google's nameservers resolve $FQDN. >> >> These are other people's caching nameservers. >> >> 4) Looks like the nameservers for healthservice.ie belong to >> topsectechnology.net. >> >> 5) Looks like those nameservers resolve $FQDN. >> >> At least that's what dig +trace tells me. >> >> >> Can't you do the auth lookups directly? Have you tried? >> >> >> So your logic in coming here is that: >> >> a) $A's caching nameservers don't resolve $FQDN. >> >> b) $B's caching nameservers do resolve $FQDN. >> >> c) You use BIND to connect to one of those entities' caching nameservers >> instead of running your own. >> >> d) Therefore, the BIND mailing list is were I should direct my ire. >> >> Did I miss anything? >> >> >> Any response you get here is going to involve changing your BIND server's >> configuration and behavior, probably to convert it from forwarding to >> caching... although grizzled veterans may tell you horror stories about >> hotels and other public wifi. >> >> -- >> >> Fred Morris >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users >> named.conf Description: Binary data > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscri
Re: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?
Am 09.01.22 um 12:57 schrieb Jason Vas Dias: Thanks Fred - Though really all I am trying to do is ensure I can access all public DNS names, which my experience shows me I cannot, using my ISP's name-servers. It seems there is a Hidden Google Internet that I cannot access unless I use Google's DNS servers, giving Google data about me to sell - this is what I am trying to avoid for the sake of god stop talking nonsense about "Hidden Google Internet" when your named does as you configured and forward to your broken ISP nameservers ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?
Thanks to all who responded !
Yes, removing my Forwarders list did the trick .
Never trust an ISP's DNS servers!
Best Regards,
Jason
On 08/01/2022, Jason Vas Dias wrote:
>
> Good day -
>
>I use BIND v9.16.24-1.fc34 on a fully up-to-date Fedora 34
>x86_64 installation as a 'Caching-Only Nameserver', and
>to serve a few local zones ( devices attaching to my
>hostapd wireless network for instance ), and to serve
>a DNS RPZ zone to direct adware / spyware hosts to 0.0.0.0.
>
>My Internet Connection is as follows:
>
> ( GSM 4g/3g modem
> WAN IP DHCP address provided by eir.com, with
> nameservers: 159.134.0.11; 159.134.0.12;
> served by DHCP
> Does DHCP and NAT for DHCP leased addresses
> ) ||
> || 100m Cat6 Ethernet Cable
> ||
> ( My Linux Laptop's Dell Thunderbolt Ethernet port
> Gets DHCP address from Modem.
>
> Hostapd provides Access Point to @ 4 devices
> connecting via DHCP; does NAT for this wireless
> DHCP subnet to the modem assigned DHCP address.
> ) / | \
> ( several Android units for testing ...)
>
>So I copy the DNS server addresses my ISP gives the
>modem with DHCP into my named.conf's forwarders clause:
>
> forwarders { 159.134.0.11; 159.134.0.12; } ;
>
>This has seemed to work fine up til now.
>
>Now, when I try to access the Irish Health & Safety
>Executive's (HSE) website to make a Coronavirus
>booster appointment, as advertised on its web-page:
>
>
> https://www2.hse.ie/screening-and-vaccinations/covid-19-vaccine/get-the-vaccine/booster-booking/
>
>where one is meant to click on the link:
>
>"Book An Appointment": https://covid19booster.healthservice.ie/
>
>to make an appointment, Firefox and Chrome both return
>"Server Not Found" errors .
>
>Running 'host' and 'dig' show NO DNS records for this address:
>
># host covid19booster.healthservice.ie
>Host covid19booster.healthservice.ie not found: 3(NXDOMAIN)
>
># dig covid19booster.healthservice.ie @159.134.0.11
>
> ; <<>> DiG 9.16.24-RH <<>> covid19booster.healthservice.ie @159.134.0.11
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5751
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: d8709a304768c6c62d5def9761d9a5a5a7041a24829eafd0 (good)
> ;; QUESTION SECTION:
> ;covid19booster.healthservice.ie. IN A
>
> ;; AUTHORITY SECTION:
> healthservice.ie. 8946IN SOA ns1.ie.topsec.com.
> hostmaster.topsec.com.
> 2022010601 3600 1200 3628800 10800
>
> ;; Query time: 46 msec
> ;; SERVER: 159.134.0.11#53(159.134.0.11)
> ;; WHEN: Sat Jan 08 14:58:38 GMT 2022
> ;; MSG SIZE rcvd: 152
>
>
> # dig covid19booster.healthservice.ie @159.134.0.12
>
> ; <<>> DiG 9.16.24-RH <<>> covid19booster.healthservice.ie @159.134.0.12
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64814
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 367dae8c9918d4ae9b2b923761d9a6a0d321e2a74da293d9 (good)
> ;; QUESTION SECTION:
> ;covid19booster.healthservice.ie. IN A
>
> ;; AUTHORITY SECTION:
> healthservice.ie. 9549IN SOA ns1.ie.topsec.com.
> hostmaster.topsec.com.
> 2022010601 3600 1200 3628800 10800
>
> ;; Query time: 42 msec
> ;; SERVER: 159.134.0.12#53(159.134.0.12)
> ;; WHEN: Sat Jan 08 14:58:40 GMT 2022
> ;; MSG SIZE rcvd: 152
>
> To show this configuration does work for other addresses:
>
> # dig www.kernel.org
>
> ; <<>> DiG 9.16.24-RH <<>> www.kernel.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40744
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: aa286ca3eb2f9d1d010061d9a70bded0d6956f6f711c (good)
> ;; QUESTION SECTION:
> ;www.kernel.org. IN A
>
> ;; ANSWER SECTION:
> www.kernel.org. 60 IN CNAME geo.source.kernel.org.
> geo.source.kernel.org.60 IN CNAME ams.source.kernel.org.
> ams.source.kernel.org.3462IN A 145.40.68.75
>
> ;; Query time: 114 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Sat Jan 08 15:00:27 GMT 2022
> ;; MSG SIZE rcvd: 140
>
>
>
> Visiting internic.net's whois server shows no records for
> covid19booster.healthservice.ie, but instead these
> error messages are displayed:
>
> Whois Lookup 'covid19booster.healthservice.ie':
> "
> No registry RDAP server was identified for this domain. Attempting
> lookup using WHOIS service.
>
> Failed to perform lookup using WHOIS service: TLD_NOT_SUPPORTED
> "
>
> As a resul
Re: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?
Thanks, but no one suggested removing my forwarders list . I figured out that must be the issue, and will try that . I thought it might be more efficient to use forwarders on my ISP's network - I see now I should not have . If someone had simply suggested removing my forwarders, I would have tried that . Thanks, all the best, Jason On 08/01/2022, G.W. Haywood via bind-users wrote: > Hi there, > > On Sat, 8 Jan 2022, Jason wrote: > >> ... >> My point is that public service websites, which provide vital >> public health services , on which people's lives and human >> rights depend , should NOT be on some >> "Google Server Accessable Only" Hidden Internet . > > And they aren't. > >> What about non-technical users, who may not have a smartphone, >> who just assume "the HSE website is down", and as a result, never >> get a Booster Appointment ? >> >> Maybe the HSE are using this situation to limit access to >> Covid vaccines & Passports only to wealthier people with smartphones >> and full-featured internet accounts ? That would get >> alot of problems off their books, and they'd have to spend >> alot less on vaccine . > > You're tilting at windmills. > >> It is frightening that there is developing this "Google User Only" >> "Hidden Internet" , accessable only to users who agree to their >> web behaviour being analysed and financially exploited by Google. > > Again, you're inventing problems which don't exist. > >> I would like to find a way to access the WHOLE internet, without >> using Google. >> ... > > You don't seem to be paying attention to the knowledgeable people who > have answered your questions. > > There's nothing wrong with BIND, nothing wrong with the DNS name that > you're, er, harping on about, there's no conspiracy, and (!) you don't > have to involve Google if you don't want to. > > You've simply borked your own setup by using broken forwarders which > you didn't need to use to begin with. You created your problems. > > Here's one of my BIND installations resolving the name that you're > having trouble with: > > $ dig +short covid19booster.healthservice.ie > hse-self-referral.swiftqueue.com. > 52.50.21.250 > 52.214.178.78 > > It Works For Me, I can browse to the location, but I try not to get in > the nameserver's way (and I had my booster a couple of months ago...) > > For some amusement and education try > > dig +trace covid19booster.healthservice.ie > > and spend some quality time with the BIND documentation. > > -- > > 73, > Ged. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?
Thanks Fred -
Though really all I am trying to do is ensure I can access
all public DNS names, which my experience shows me I
cannot, using my ISP's name-servers.
It seems there is a Hidden Google Internet that I cannot access
unless I use Google's DNS servers, giving Google data
about me to sell - this is what I am trying to avoid .
RE:
> Can't you do the auth lookups directly? Have you tried?
You mean add topsectechnology.net's DNS servers to
my Forwarders list ?
How do I find out what they are, when the domain
cannot be looked up by ICANN's WHOIS service ?
And really this would not be a solution, every time I get an
NXDOMAIN error, I'd have to access multiple web-sites
to find the authoritative nameserver for the domain
(which fails for topsectechnology.net anyway), and
then add them to my Forwarders list ?
Is this the way the DNS is meant to work these days ?
I thought the DNS was meant to be public and global.
I see that nowadays it is not . What a shame !
How did we let this happen ?
And this is meant to be a vital public information service !
Why choose to hide the domain name that allows the public
to make a Covid Booster booking, unless the intent is
to exclude a section of society from accessing it ?
> the BIND mailing list is were I should direct my ire.
Isn't this the BIND mailing list we are discussing this on?
Is there another one I should be using ? If so, please let
me know .
> Any response you get here is going to involve changing your
> BIND server's configuration and behavior, probably to convert
> it from forwarding to caching...
Fine ! I am just using a slightly modified Red Hat
caching nameserver example named.conf, enclosed .
Why isn't this a caching nameserver ?
If anyone could suggest how to turn my config into one
that is able to query the Google Hidden Internet, without
accessing a Google Server, please let me know.
Thanks & Best Regards,
Jason
On 08/01/2022, Fred Morris wrote:
> Wow.
>
> 1) You're using BIND as a caching nameserver.
>
> So you say. Does the nameserver do its own upstream (authoritative)
> lookups? If yes, then the term of art is "recursive / caching"; otherwise
> the term is "forwarding".
>
> Looks like you're configuring your ISP's nameservers as forwarders.
> Therefore the proper term is "forwarding".
>
> 2) Your ISP's nameservers fail to resolve $FQDN.
>
> These are other people's caching nameservers.
>
> 3) Google's nameservers resolve $FQDN.
>
> These are other people's caching nameservers.
>
> 4) Looks like the nameservers for healthservice.ie belong to
> topsectechnology.net.
>
> 5) Looks like those nameservers resolve $FQDN.
>
> At least that's what dig +trace tells me.
>
>
> Can't you do the auth lookups directly? Have you tried?
>
>
> So your logic in coming here is that:
>
> a) $A's caching nameservers don't resolve $FQDN.
>
> b) $B's caching nameservers do resolve $FQDN.
>
> c) You use BIND to connect to one of those entities' caching nameservers
> instead of running your own.
>
> d) Therefore, the BIND mailing list is were I should direct my ire.
>
> Did I miss anything?
>
>
> Any response you get here is going to involve changing your BIND server's
> configuration and behavior, probably to convert it from forwarding to
> caching... although grizzled veterans may tell you horror stories about
> hotels and other public wifi.
>
> --
>
> Fred Morris
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
//
// named.caching-nameserver.conf
//
// Provided by Red Hat caching-nameserver package to configure the
// ISC BIND named(8) DNS server as a caching only nameserver
// (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// DO NOT EDIT THIS FILE - use system-config-bind or an editor
// to create named.conf - edits to this file will be lost on
// caching-nameserver package upgrade.
//
options {
listen-on port 53 { 127.0.0.1; 192.168.122.1; 192.168.4.1;
192.168.42.10; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
secroots-file "/var/named/data/named.secroots";
recursing-file "/var/named/data/named.recursing";
dnssec-enable no;
dnssec-validation no;
resolver-query-timeout 64;
resolver-retry-interval 8;
max-retry-time 64;
managed-keys-director
