I have updated the TXT (SPF) records in my domain hosted DNS without the space.
I have tried to check the updated the TXT record in the linux terminal using the dig and host commands, but I'm seeing extra white space in the updated record.
For example:
The updated record in the DNS:
"v=spf1 spf.protection.outlook.com 1.2.3.4 -all"
But the output getting in the terminal using the command "dig txt domain.com +short"
"v=spf1 spf.protection. outlook. com 1.2" "3.4 -all"
checked with all type of OS platform terminals (Linux-CentOS, Ubuntu,Windows-CMD, Mac OS terminal).
Note: I have tried to eliminate the space using the sed command and it has worked.
I just want to confirm where the issue is, whether it is from the DNS provider or elsewhere.
DNS has a limit in the amount of text it will allow in a single string, however, you can work around this by breaking it up into multiple double-quoted, space-separated strings according to the standard defined by RFC4408 section 3.1.3:
For example:
IN TXT "v=spf1 .... first" "second string..."
MUST be treated as equivalent to
IN TXT "v=spf1 .... firstsecond string..."
It's common to see this in large records, especially DKIM keys and long SPF records. It looks like your provider is possibly doing this automatically, and is nothing to worry about, so long as you're not creating records that are nearing the 512-byte limit.
you can use one of online SPF record lookup tools to troubleshoot various issues with SPF record, e.g. this one -> https://easydmarc.com/tools/spf-lookup
Let's say you have a resolv.conf file that's something like this.
nameserver 192.168.0.7
nameserver 192.168.0.8
domain somedomain.local
Then let's say you just changed it to this.
nameserver 192.168.0.7
nameserver 192.168.0.8
search somedomain.local
Would these both do the same thing? Is one slightly better than the other?
Why would declaring both a domain and search not be recommended?
The existence of both keywords are probably historically. Only one of them can be specified in the resolv.conf (the parser built into glibc is supposed to use the last one it encounters). The search keyword is slighty more powerful, since it allows multiple entries, and has the ndots option.
man 5 resolv.conf currently reads:
The domain directive is an obsolete name for the search directive that handles one search list entry only.
Stian Skjelstad summarized the benefits of using search over domain nicely.
I am attempting to set up mailgun on my server.
i am editing the DNS records through whm.
One record is causing me issues
"v=spf1 include:mailgun.org ~all"
I have set this to a TXT record - but if I don't add quotes around the record it gets changed to v=spf1.
However mailgun is not recognising this record. (it recognises another TXT record in double quotes though - however that one is not set as my domain name but rather k1._domainkey
Is there a way to enter this in WHM without the double quotes - or is it likely to be a problem elsewhere (and how do I check that it is correctly set?)
I am quite new to anything other than setting MX records so if more info is needed just let me know.
Thanks for the help in advance!
Well wouldn't you know I just managed to sort it.
If anyone is having the same issue simply append a full stop (period for our american friends :-D) to the end of your domain name.
so mydomain.com becomes mydomain.com.
I had done this for other records by default as I just copied other entries but had missed it off this record.
Perhaps someone clever can tell me why the full-stop is required?
As an overall solution i'd like to split dns resolving between different servers, using dnsmasq.
i.e. Default to dns server A, unless explicitly set to dns server B per host (mac).
I'd like to split my network into dnsmasq tagged subnets, for this example say:
192.168.1.80-150 = green
192.168.1.40-50 = red
I would like dhcp leases to be handed by, by -default- tagged green, except for a few specific MACs where I would like to hand out the red tag.
I have this part working successfully (I believe), where i explicitly set it by MAC - but what i would like is for everything -unless specified otherwise- to default to green.
I would then like to say "for all green tags, give them dns server A as their resolver", "for all red tags, give them dns server B as their resolver".
is this possible?
I have the following config that does not seem to work:
--8<--
dhcp-range=set:green,192.168.1.80,192.168.1.150,infinite
dhcp-range=tag:red,192.168.1.40,192.168.1.50,infinite
dhcp-option=net:green,option:dns-server,8.8.8.8,8.8.4.4
dhcp-option=net:red,option:dns-server,192.168.1.11
dhcp-host=AA:BB:CC:DD:CC:BB,redhost1,192.168.1.41,infinite,net:red
dhcp-host=BB:CC:DD:AA:BB:00,greenhost1,192.168.1.81,infinite,net:green
dhcp-option=option:router,192.168.1.1
--8<--
This does not seem to work however, I have different hosts being assigned different ip addresses based on whether i have matched their MAC, and then it seems as if the dns server is not correctly being handed out.
I believe the dns server is not being handed out because a "cat /etc/resolv.conf" on one of the hosts shows 127.0.0.1.
To summarise my queries:
Can i make everything default to 'green', unless explicitly set to 'red' by MAC (at the moment I am having to explicitly put the mac of everything into the conf file)?
Can i specify different DNS servers, for different tagged networks?
For extra clarity I am a bit confused about the different between "tag" and "set" and in googling have found references to both, a short and clean definition of these would be great.
thanks very much
ok, i fixed it (wrt my particular request) and i'll post what i've got here in case it helps someone else.
so my requirement was handing out different dns server (and perhaps different gw) to different hosts, and this seems to work:
dhcp-range=set:green,192.168.1.80,192.168.1.150,infinite
# red network
dhcp-host=11:22:33:44:55:66,hosta,192.168.1.11,infinite,set:red
dhcp-host=66:55:44:33:22:11,aa:bb:cc:dd:ee:ff,hostb,192.168.1.12,infinite,set:red
# green network mobile
dhcp-host=dd:dd:dd:dd:dd:dd,android1,192.168.1.21,infinite,set:green
dhcp-host=cc:cc:cc:cc:cc:cc,android2,192.168.1.22,infinite,set:green
unless expicility set otherwise, everything is tagged green. Some certain MACs are tagged red. Then to do the different dns server and different gw you can do:
# options
dhcp-option=tag:green,option:dns-server,192.168.1.1,192.231.a.b # ,8.8.8.8,8.8.4.4
dhcp-option=tag:red,option:dns-server,192.168.1.c
dhcp-option=tag:green,option:router,192.168.1.1
dhcp-option=tag:red,option:router,192.168.1.c
some other notes / context that i found helpful about this, and also about the net / set / tag options:
The optional set: sets an alphanumeric label which marks this network so that dhcp options may be specified on a per-network basis. When it is prefixed with 'tag:' instead, then its meaning changes from setting a tag to matching it. Only one tag may be set, but more than one tag may be matched.
More than one tag can be set in a dhcp-host directive (but not in other places where "set:" is allowed)
This system evolved from an earlier, more limited one and for backward compatibility "net:" may be used instead of "tag:" and "set:" may be omitted. (Except in dhcp-host, where "net:" may be used instead of "set:".) For the same reason, '#' may be used instead of '!' to indicate NOT.
therefore i think it's safe to just:
use set and tag, and avoid using net (since it's the old way)
use set in your dhcp-range and dhcp-host, to assign the tags, and
use tag in your options to match the tags that you've already set.
as an aside on of those dhcp-hosts you can see with multiple mac addresses, because it's the eth0 and wlan mac's for the same box.
seems to work for me anyway, perhaps this will help someone.
why not change the mind to setup 2 dhcp sections over 2 vlans with just 1 dnsmasq service, and make the 2 vlans communicate with each other through their gateways (or not).
I'd like to query the DNS records until get the right domain name.
For instance, given www.subdomain.site.com.br, be able to dig from .br until site.com.br.
Which is the most (protocol-speaking) way to achieve that? An recipe using dig/nslookup would be best.
Thanks.
dig +trace www.subdomain.site.com.br
will show you exactly what happens.
dig www.mysite.domain.com #a.root-servers.net
you'll get the next level from there. Just replace the portion after the '#' and keep recursing until you query a server that gives an answer rather than additional information