I would like to force the http_poller to use ipv6 first prior to ipv4.
The host running logstash is dual stacked and the target host also.
The issue lies in the ACL on the target host only accepting requests from the IPv6 addresses on the vhost configured.
curl works as it is default ipv6 first if dual stacked and ipv6 addresses are returned by dns (but also ipv4).
When in touch with the supplier of the endpoint it seemed that we are going over ipv4 when using the http_poller input from logstash iso ipv6, I see no options in the plugin to force ipv6 and the supplier is not going to change its dns, nor allowing our ipv4 address.
I know that I could create a workaround with having an exec input that handles the request, but I consider this only as a last resort.
Someone who has an idea on how to solve it?
Update: I already looked into the info of manticore http client, but did not find a solution there (thanks Badger for reminding me to share the fact that I already looked into this)
Related
I am trying to switch my dynamic DNS from IPv4 to IPv6, but I am encountering a strange issue. The device is accessible via its raw IPv6 address, but whatever dynamic DNS server I use, it always results in an IP address not found issue. The IPv4 one works fine though. The server is also correctly configured, otherwise the raw address would not work.
What is even stranger is that services like http://ipv6-test.com seem to be able to verify that IPv6 functionality exists and also which web server I use. They also list the corresponding name servers.
I tried the dynamic DNS services of spdyn, dynv6, and ddnss. I also tried noip, but it seems they only support IPv4 for free. (My IPv4 one is with noip.)
Does anybody have some advice? I'm thankful for any help!
Most probably your network is not supporting IPv6.
Is there a good API alternative to res_ninit?
There are problems with this call because the res->_u.ext.nscount6 and res->nscount do not reflect correct numbers. Adding a IPv6 address to /etc/resolv.conf still results in the nscount increasing where you would have expected the nscount6 to increase.
An older glibc version seems to increase both nscount and nscount6 for a IPv6 address in /etc/resolv.conf.
I am currently parsing resolv.conf directly because i am unable to depend on the res_ninit call. But this is fine for Manual DNS.
When it comes to DHCP DNS, then i need an API to give me the result. There is no other way (that i can think of) to determine the DNS IP addresses over DHCP.
Tried posting in other places within the board but not of help so far. E.g.
Retrieve IPv4 and IPv6 nameservers programmatically
res_ninit and res_init only ever read name server information from /etc/resolv.conf. You can always get the same data name servers by parsing /etc/resolv.conf yourself and examining the nameserver lines. If there is no nameserver line, the default 127.0.0.1 will be used.
I don't think it is necessary to provide an API for that because the file format is so simple that is likely more difficult to use the API than to read the file instead.
Name server assignment over DHCP is implemented by rewriting /etc/resolv.conf if there is no local caching resolver running on the machine. The exact mechanism used for that is distribution-specific, e.g. Debian uses resolvconf if it is installed.
If a local caching resolver is running on the system (such as dnsmasq or Unbound), name servers over DHCP can be directly configured in that caching resolver. In this case, /etc/resolv.conf will keep pointing to the same name server, typically by listing nameserver 127.0.0.1 or no name server information at all (which is the default).
Does the Linux SNMP agent support IPv6? I'm working with net-snmp 5.5. It's working fine with IPv4 address set and get operations, but with an IPv6 address it leads to unknown host.
What's the problem, and how do I resolve it?
Happened to come across this question while searching for something else and figured I could add my 2 cents.
The IPv6 address in a net-snmp command is a little different from an IPv4 address. You need to use the udp6: prefix and specify the port number.
"udp6:[<ipv6 address here>]:161"
The full command should look something like this:
snmpset -v 1 -c private "udp6:[<ipv6 address here>]:161" 1.3.6.1.4.1.318.1.1.26.4.4.1.4.1 i 7
edit: this works for a Windows environment, but may be the same for Linux
In addition to listening for udp6 packets, it also seems you must specify an additional, separate community for ipv6 requests. Without both changes to snmpd.conf snmp queries via ipv6 are ignored.
agentAddress udp:161,udp6:161
rocommunity6 public default
I am implementing a dns client, in which i try to connect to a local dns server, but the dns server is returning the message with an error code 5 , which means that its refusing the connection.
Any thoughts on why this might be happening ?? Thanks
DNS response error code 5 ("Refused") doesn't mean that the connection to the DNS server is refused.
It means that the DNS server refuses to provide whatever data you asked for, or to do whatever action you asked it to do (for example a dynamic update).
Since you mention a "connection", I assume that you are using TCP?
DNS primarilly uses UDP, and some DNS servers will refuse all requests over TCP.
So the solution might be as simple as switching to UDP.
Otherwise, assuming you are building your own DNS client from scratch, my first guess would be that you are formatting the request incorrectly. Eventhough the DNS protocol seems fairly simple, it is very easy to get this wrong.
Finally, the DNS server may of course simply be configured to refuse requests for whatever you are asking.
explicitly adding the network from which i wanted to allow-recursion fixed this problem for me:
these two lines added to /etc/bind/named.conf.options
recursion yes;
allow-recursion { 10.2.0.0/16; };
Policy enforcement?
The DNS server could be configured to accept only connections from certain hosts.
Hmm, if you're able to access StackOverflow you have a working DNS server SOMEwhere. Try doing
host -v stackoverflow.com
and look for messages like
Received 50 bytes from 192.168.1.1#53 in 75 ms
then pick the address out of that line and use THAT as your DNS - it's obviously willing to talk to you.
If you're on Windows, use NSLOOKUP for the same purpose. Your name server's address will be SOMEwhere in the output.
EDIT:
When I'm stuck for a DNS server, I use the one whose address I can remember most easily: 4.2.2.2 . See how that works for you.
You might try monitoring the conversation using WireShark. It can also decode the packets for you, which might help you determine if your client's packets are correctly encoded. Just filter on port 53 (DNS) to limit the packets captured by the trace.
Also, make sure you're using UDP and not TCP for queries; TCP should be used primarily for zone transfers, not queries.
Imagine a user sitting at an Ethernet-connected PC. He has a browser open. He types "www.google.com" in the address bar and hits enter.
Now tell me what the first packet to appear on the Ethernet is.
I found this question here: Interview Questions on Socket Programming and Multi-Threading
As I'm not a networking expert, I'd like to hear the answer (I'd assume it is "It depends" ;) ).
With a tool like Wireshark, I can obviously check my own computers behaviour. I'd like to know whether the packets I see (e.g. ARP, DNS, VRRP) are the same in each ethernet configuration (is it dependent on the OS? the driver? the browser even :)?) and which are the conditions in which they appear. Being on the data-link layer, is it maybe even dependent on the physical network (connected to a hub/switch/router)?
The answers that talk about using ARP to find the DNS server are generally wrong.
In particular, IP address resolution for off-net IP addresses is never done using ARP, and it's not the router's responsibility to answer such an ARP query.
Off-net routing is done by the client machine knowing which IP addresses are on the local subnets to which it is connected. If the requested IP address is not local, then the client machine refers to its routing table to find out which gateway to send the packet to.
Hence in most circumstances the first packet sent out will be an ARP request to find the MAC address of the default gateway, if it's not already in the ARP cache.
Only then can it send the DNS query via the gateway. In this case the packet is sent with the DNS server's IP address in the IP destination field, but with the gateway's MAC address on the ethernet packet.
You can always download wireshark and take a look.
Though to spoil the fun.
Assuming, the IP address of the host is not cached, and the MAC address of the DNS server is not cached, the first thing that will be sent will be a broadcast ARP message trying to find out the MAC address of the DNS server (which the router will respond to with its own address).
Next, the host name will be resolved using DNS. Then the returned IP address will be resolved using ARP (again the router will respond with its own address), and finally, the HTTP message will actually be sent.
Actually, it depends on a variety of initial conditions you left unspecified.
Assuming the PC is running an operating system containing a local DNS caching resolver (mine does), the first thing that happens before any packets are sent is the cache is searched for an IP address. This is complicated, because "www.google.com" isn't a fully-qualified domain name, i.e. it's missing the trailing dot, so the DNS resolver will accept any records already in its cache that match its search domain list first. For example, if your search domain list is "example.com." followed by "yoyodyne.com." then cached resources matching the names "www.google.com.example.com." "www.google.com.yoyodyne.com." and finally "www.google.com." will be used if available. Also note: if the web browser is one of the more popular ones, and the PC is running a reasonably current operating system, and the host has at least one network interface with a global scope IPv6 address assigned (and the host is on a network where www.google.com has AAAA records in its DNS horizon), then the remote address of the server might be IPv6 not IPv4. This will be important later.
If the remote address of the Google web server was locally cached in DNS, and the ARP/ND6 cache contains an entry for the IPv4/IPv6 address (respectively) of a default router, then the first transmitted packet will be a TCP SYN packet sourced from the interface address attached to the router and destined for the cached remote IPv4/IPv6 address. Alternatively, the default router could be reachable over some kind of layer-2 or layer-3 tunnel, in which case, the SYN packet will be appropriately encapsulated.
If the remote address of the Google web server was not locally cached, then the host will first need to query for the A and/or AAAA records in the DNS domain search list in sequence until it gets a positive response. If the first DNS resolving server address in the resolver configuration is in one of the local IPv4 subnet ranges, or in a locally attached IPv6 prefix with the L=1 bit set in the router advertisement, and the ARP/ND6 cache already contains an entry for the address in question, then the first packet the host will send is a direct DNS query for either an A record or a AAAA record matching the first fully-qualified domain name in the domain search list. Alternatively, if the first DNS server is not addressable on-link, and a default router has an ARP/ND6 cache entry already, then the DNS query packet will be sent to the default router to forward to the DNS server.
In the event the local on-link DNS server or a default router (respectively, as the case above may be) has no entry in the ARP/ND6 cache, then the first packet the host will send is either an ARP request or an ICMP6 neighbor solicitation for the corresponding address.
Oh, but wait... it's even more horrible. There are tweaky weird edge cases where the first packet the host sends might be a LLMNR query, an IKE initiation, or... or... or... how much do you really care about all this, buckaroo?
It depends
Got that right. E.g. does the local DNS cache contain the address? If not then a DNS lookup is likely to be the first thing.
If the host name is not in DNS cache nor in hosts file, first packet will go to DNS.
Otherwise, the first packet will be HTTP GET.
Well, whatever you try to do, the first thing happening is some Ethernet protocol related data. Notably, Ethernet adapters have to decide whether the Ethernet bus is available (so there's some collision detection taking place here)
It's hard to answer your question because it depends a lot on the type of ethernet network you're using. More information on Ethernet transmission can be found here and here