I got a DNS internal query log file and I would like to do analysis on it, so onw record looks like this:
18-Jun-2017 04:00:10.139 client #XXXXXXXXXXXX ip-address#number (ip-address): view internal: query: ip-address IN AAAA + (ip-address in the format of ipv4)
I am really new to this so I tried to search on line but I couldn't find what does the "+" mean in the record, and as far as I understand, AAAA should represent the ipv6 ip format, why I got a following ipv4 address following it ?
Can some one explain it to me what does this record means or some links I could read myself ?
Many thanks !!
You're right AAAA (or the quad record) is for IPV6 addresses. The IPV6 addressing scheme allows for trailing or leading zeros to be omitted, so an IPV4 address of 192.169.1.1 may be represented as 00:00:00:00:C0:A8:01:01 which without the leading zeros is C0:A8:01:01 or 192.168.1.1 if your text editor converts Hex to Decimal.
Related
I have added the following line in my hosts file: C:\Windows\System32\drivers\etc\hosts
127.0.0.1 firsthostfirsthostfirsthostfirsthostfirsthostfirsthostfirsthost
The above is working fine(length is 63), able to ping and the host is responding. But if I put the hostname as
127.0.0.1 firsthostfirsthostfirsthostfirsthostfirsthostfirsthostfirsthostf
(Here the length is 64.),a message is shown: "Ping request could not find host firsthostfirsthostfirsthostfirsthostfirsthostfirsthostfirsthostf. Please check the name and try again."
Please help me to understand the cause. Any reference link would be appreciated.
Thanks in advance.
RFC 1035 limits the length of a fully-qualified domain name (FQDN) to 255 characters, and each "label" - the portion between dots - to 63 characters.
Your first example works because it's a 63 character label. Your second example fails because it doesn't comply with the rules set out in RFC 1035.
Over at dmarc.org, it's suggested that IN TXT records of DNS could be written in a special form within the zone file to make them not overflow the lines in your text editor.
The DMARC policy record might look like this when retrieved using a
common command-line tool:
% dig +short TXT _dmarc.example.com.
"v=DMARC1\; p=none\; rua=mailto:dmarc-feedback#example.com"
To publish such a record, the DNS administrator for the Domain Owner
creates an entry like the following in the appropriate zone file
(following the conventional zone file format):
; DMARC record for the domain example.com
_dmarc IN TXT ( "v=DMARC1; p=none; "
"rua=mailto:dmarc-feedback#example.com" )
I've tried following the example in my actual zone file with NSD; however, when I then query the domain, I actually get the results wrapped up on multiple lines, too.
% dig +short TXT _dmarc.example.su
"v=DMARC1\; " "p=reject\; " "rua=mailto:rua-dmarc#example.su"
Is this expected? Is this likely to break some software that's supposed to parse these TXT records to get the DMARC / SPF / DKIM / etc?
The individual components of a TXT record may only contain up to 255 characters each, since they're transmitted on the wire in <length><data ...> format.
Any code that's potentially expecting to take more than 255 characters SHOULD be able to coalesce multiple components into a single character array.
In master file format the braces surrounding the strings indicate that multiple components are to be included in a single TXT record - without them this would have created two separate TXT records, and the relative order of the two records would be undefined and subject to change.
It's hard to tell since it will depend on the final implementation of the DMARC checker. However, even detailed in the DMARC document, a DMARC record is no such big that you could overflow your editor.
In my case, using the last opendmarc package on Ubuntu Trusty (14.04) along with Postfix, made the daemon crash when processing some weird/malformed DMARC DNS records (but not exactly the case you mention).
I would simply add the one-line approach and play it safe, not just because of a possible break of the checker software, but even worse would be getting your mail rejected because policy doesn't seem to be alligned when it actually is!
So I'd just add something like this:
_dmarc.example.su IN TXT "v=DMARC1; p=reject; rua=mailto:rua-dmarc#example.su"
I used wireshark to collect data from some sites, and then used tcpdump to get it as a text file. For the project I'm working on, I want to count how many DNS resolutions are involved in accessing a particular website, and what the nature of the DNS responses was. The problem is I don't really understand the output from wireshark or how to interpret it to find what I'm looking for. For instance, here is a line:
21:08:05.454852 IP 10.0.0.2.57512 > ord08s09-in-f21.1e100.net.https:
Flags [.], seq 1:1419, ack 55, win 65535, options [nop,nop,TS val
1348891674 ecr 2473250009], length 1418
What do the different parts of this mean, and what will the data I'm looking for look like? I'm worried I might be using Wireshark incorrectly without knowing it.
I used wireshark to collect data from some sites, and then used tcpdump to get it as a text file.
Most people who use both tools use them for the opposite purposes. :-) I.e., they use tcpdump to capture traffic into a file and then read the file with Wireshark. If you're only using Wireshark to capture traffic, that's probably overkill - you can do the same thing with dumpcap or possibly even tcpdump.
The output you're showing is text output, so, if you "used tcpdump to get it as a text file", it's output from tcpdump, not from Wireshark; text output from Wireshark would look different. If you "used wireshark to collect data from some sites, and then used tcpdump to get it as a text file", the output from Wireshark is either a pcap file or a pcap-ng file, which is a binary file, and is completely uninterpreted raw data. The interpretation of the data in your example is being done by tcpdump, not Wireshark.
What the output is saying is:
"21:08:05.454852": the packet arrived at 21:08:05 and a fraction of a second, local time.
"IP": the packet is an IPv4 packet.
"10.0.0.2.57512 > ord08s09-in-f21.1e100.net.https": the packet is from IP address 10.0.0.2, port 57512, to the IP address whose for which the host name is "ord08s09-in-f21.1e100.net", and the port for "https", which is port 443.
See the tcpdump man page, and a description of TCP, for details on the rest of the line.
The key point here is that this is NOT DNS traffic! It's probably "HTTP-over-SSL", or "https", traffic.
In tcpdump, DNS traffic would look like
11:06:25.247272 IP 10.0.1.3.50953 > 10.0.1.1.domain: 7088+ A? www.kernel.org. (32)
11:06:25.282723 IP 10.0.1.1.domain > 10.0.1.3.50953: 7088 3/0/0 CNAME pub.us.kernel.org., A 149.20.4.69, A 198.145.20.140 (85)
or
11:06:30.622744 IP 10.0.1.3.62767 > 10.0.1.1.domain: 2439+ A? e3191.c.akamaiedge.net.0.1.cn.akamaiedge.net. (62)
11:06:30.639279 IP 10.0.1.1.domain > 10.0.1.3.62767: 2439 1/0/0 A 184.85.109.15 (78)
"A?" means that a query is being done for an A record; "CNAME" means that a CNAME record is being returned (i.e., "www.kernel.org" is an alias for "pub.us.kernel.org", and "A" means that an A record is being returned, giving an IPv4 address.
In Wireshark or TShark, it would look like:
12.316361 10.0.1.3 -> 10.0.1.1 DNS Standard query 0xc2fa A 1.courier-sandbox-push-apple.com.akadns.net
12.332894 10.0.1.1 -> 10.0.1.3 DNS Standard query response 0xc2fa A 17.149.34.59 A 17.149.34.61 A 17.149.34.62 A 17.149.34.63 A 17.149.34.57
or
15.163941 10.0.1.3 -> 10.0.1.1 DNS Standard query 0x168c A www.gnu.org
15.176266 10.0.1.1 -> 10.0.1.3 DNS Standard query response 0x168c CNAME wildebeest.gnu.org A 208.118.235.148
If you're only trying to capture DNS packet, you should use a capture filter such as "port 53" or "port domain", so that non-DNS traffic will be discarded. That filter will work with Wireshark, TShark, or tcpdump (as they use the same libpcap code for packet capture).
I am trying to write a script that will take in a BIND zone file, grab all of the A records, in the format host ip. I've done that by grep -w 'A' "$A_ZONE"|awk '{print $1,$4}'|sort -V, to skip the IN A part. Now, I need to extract PTR records from all of the reverse zones that I have. Those are grouped by /24 subnets, so if I have a PTR record for 10.0.0.1, it would be in the 0.0.10.in-addr.arpa.zone file, as 10 IN PTR host.domain.tld. Seeing as that is a bit convoluted, I'm not sure how to extract the IP well, so that it would be in the format of the first file that I extracted, host ip.
Any suggestions?
You can use the following command:
egrep '^[0-9]+' 0.0.10.in-addr.arpa.zone | \
perl -p -e 's/^(\d+).*\s(\S+)\s*$/$2 10.0.0.$1/'
Output:
host.domain.tld. 10.0.0.10
It greps all the records that start with a number, and match the number and hostname and reverse them. The IP address is then constructed along with the hostname.
Note that in the command I showed, the subnet is hardcoded in the regexp, but you could apply similar strategy to extract it from your filename plug it into the regex.
You may also want to consider running your zone files through named-compilezone so as to make sure that they are in a canonical format suitable for scripting.
I have a third party dll, that is supposed to return machine name.
Sometimes it returns
\\John-PC
some other times it returns
\\192.168.1.120
and recently i discovered that it returns something like this
\\[ef80::32d6:2255:27dd:123c]
So what is the third option?
If it is not a bug or MAC orelse, could i convert it to \192.168.1.120 and get happy???
It is the IPv6 version of the IPv4 address 192.168.1.120
. It also amuses me how your DLL seems to be indecisive with what to return.
It's an IPv6 address. IPv6 allows you to leave out sections that are equal to 0, hence the ::.
The 3rd option is a IPv6 address