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.
Related
AWS automatically changes the well known port numbers to name.
For example 554 to rtsp.
When I am installing iptable rules, with the port number as 554, its getting changed to rtsp. This is creating problem when searching because my program passes 554 as parameter.
How to make sure that the AWS doesn't change the number to name ?
In the picture we can see the dpt:rtsp, which actually should be dpt:554.
Perhaps you're looking for iptables --list -n? The -n prints "numeric output of addresses and ports."
Say I have these two records defined:
*.example.com CNAME <some name>
foo.example.com TXT <some text>
What is expected to happen if I run a DNS query like this?
dig TXT foo.example.com
I would expect to get the TXT record defined above in the answer section, since it's more explicitly defined. But, what I get from my DNS provider is the CNAME defined for the wildcard.
I've raised this issue with them, and they say they are following the correct behaviour. This is the explanation they gave me:
Refer section 2.4 in RFC1912 about "Common DNS errors". http://www.rfc-editor.org/rfc/rfc1912.txt "A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record."
Basically, this means that, if you add a CNAME record for *.example.com, it will always take priority over any other record, even if those records are added for a specific subdomain, they're still ignored. There is nothing we can do in this case. It's how DNS is supposed to work, according to the DNS-standard.
Is this correct? Does the section in the referred RFC cover the case of a wildcard? Can anyone give me an authoritative answer and provide a link to the source?
Wikipedia page on DNS wildcard is pretty clear with examples (see the one about host1.example).
In short, a wildcard is only used if the "direct" full name is not found.
You can find all the explanations in section 4.3.2 of https://www.rfc-editor.org/rfc/rfc1034 and specifically point 3.a and point 3.c:
a. If the whole of QNAME is matched, we have found the
node.
If the data at the node is a CNAME, and QTYPE doesn't
match CNAME, copy the CNAME RR into the answer section
of the response, change QNAME to the canonical name in
the CNAME RR, and go back to step 1.
Otherwise, copy all RRs which match QTYPE into the
answer section and go to step 6.
[..]
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see if a
the "*" label exists.
See how it specifically first searches for the full name, with extra condition if it is a CNAME, but this is not your case if you query for a TXT.
In your case if you query for the TXT record specifically, then that should be returned, irrespective of any wildcard.
In fact the TXT on foo.example.com will hide any other type, a CNAME request on it, should not return the value in the wildcard but instead stop with NOERROR NODATA meaning that the name exists, just not for this type.
This is exactly the host1.example case in the above Wikipedia page.
It is very easy to try in fact.
With this zonefile:
$TTL 1
# IN SOA localhost. root.localhost. (1 604800 86400 419200 604800)
IN NS a.example.org.
IN NS b.example.org.
IN NS c.example.org.
*.example.com. IN CNAME foobar.example.net.
foobar.example.com. IN TXT "I am here."
(the beginning is just boilerplate to have bind really load the zone)
if you do dig #127.0.0.1 foobar.example.com TXT you get as expected:
;; ANSWER SECTION:
foobar.example.com. 1 IN TXT "I am here."
if you query for any other record type on same name, including CNAME you get NOERROR without any CNAME in reply (the wildcard is hidden by the explicit name in zonefile, and you get NOERROR but no data for any other record type than TXT on this name as this is the only record type in the zonefile) and the wildcard works for any other name, like dig #127.0.0.1 not-foobar.example.com TXT gives:
;; ANSWER SECTION:
not-foobar.example.com. 1 IN CNAME foobar.example.net.
The explanations you are given are not the correct ones and do not apply on your use case. The quote would only apply to this kind of (invalid) configuration:
*.example.com. CNAME <some name>
*.example.com. TXT <some text>
but this is not related to the wildcard, the same problem appears with the following configuration that will be rejected by any compliant nameserver:
foobar.example.com. CNAME <some name>
foobar.example.com. TXT <some text>
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.
We are trying to forward all emails to a specific email address. I think everything is set up okay, such as 'main.cf' and 'virtual-regexp' files. If we put the following in the 'virtual' file, the forwarding works correctly:
#ourmail.com mainid#ourmail.com
However, if we try to use the following in 'virtual' to send ALL email to the ID, it ignores it and sends it to the original user:
(.*) mainid#ourmail.com
We got the idea for the above from the following question and answer:
postfix 2.9.6.1 forward all mail to an external mail address
Any ideas why the pattern '(.*)' doesn't work? We've tried so many different patterns that our heads are starting to spin.
we solved the issue.
You need to complete the steps listed in the link above. But, in addition, you need to comment out the following lines in main.cf (if they are there) before restarting the postfix process:
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_alias_domains = hash:/etc/postfix/virtual
In a DNS zone file, for the type 'A', what is the difference between the name '*' and the name'#'?
What does each do?
* A myIp
# A myIp
Also if anyone knows a nice tutorial on editing and fine-tuning DNS zone file in general I'd appreciate it.
Thanks!
The # symbol represents the current (fully qualified) zone name, as usually set with $ORIGIN.
The * symbol is the wildcard label - the DNS server will respond to queries for unknown labels with the data from here
The # symbol means that nothing comes before the domain name and * means that anything can come before the domain name.
Refer: http://www.ipprimer.com/dns.cfm