Springe zum Inhalt

Schlagwort: DNS

Veröffentlicht am

Mit der Version 2.2.1 von pfSense wurde der alte DNS Forwarder durch den DNS Resolver Unbound ersetzt. Nach dem Update konnte nahtlos umgeschaltet werden, bei Neuinstallationen wird der DNS Resolver als Default eingestellt.

Probleme gibt es allerdings, wenn im alten DNS Forwarder Source-IPs für feste Domain-Weiterleitungen eingetragen sind. Diese werden benötigt, wenn z.B. eine Firmendomain von einem über IPSEC erreichbaren Firmen-DNS aufgelöst werden soll. Der neue DNS Resolver bietet solch eine Einstellung nicht. Ohne besondere Einstellungen werden die DNS-Requests zwar an den richtigen entfernten DNS addressiert, aber über das Default-Gateway und nicht über den IPSEC-Tunnel abgesendet.

Abhilfe schafft hier, beim DNS Resolver unter Outgoing Network Interfaces nur das LAN-Interface auszuwählen.

Nach bisherigen Tests werden damit Anfragen an Domains aus den Domain Overrides mit der korrekten Source-IP versehen. Alle anderen Anfragen an externe (z.B. per PPPoE oder DHCP erhaltene) DNS werden korrekt maskiert.

Weitere Informationen im pfSense-Forum.

Veröffentlicht am

Ab und zu findet man im weiten Netz auch Konfigurationen, in denen für den MX-Record einer Domain ein CNAME geliefert wird. RFC2181 verbietet ausdrücklich, für den MX-Record einen CNAME zu verwenden:

10.3. MX and NS records
 
   The domain name used as the value of a NS resource record, or part of
   the value of a MX resource record must not be an alias.  Not only is
   the specification clear on this point, but using an alias in either
   of these positions neither works as well as might be hoped, nor well
   fulfills the ambition that may have led to this approach.  This
   domain name must have as its value one or more address records.
   Currently those will be A records, however in the future other record
   types giving addressing information may be acceptable.  It can also
   have other RRs, but never a CNAME RR.

Es ist also ausdrücklich verboten, auf eine MX-Anfrage einen CNAME-Record zu liefern. Ganz praktisch: der PHP-Mailer von 1&1 verschickt an CNAME-Records bei einer MX-Anfrage keine E-Mails, sondern deren Mailsystem lehnt dann den Versand der E-Mail ab.

Veröffentlicht am

Mit der Einführung von DNSSEC für verschiedene TLDs haben sich die Erfordernisse an die eingesetzte Firewall-Software erhöht. Da gleichzeitig im BIND9 die DNSSEC-Abfrage per Default eingeschaltet wurde, sollte getestet werden, ob die Firewall-Software für EDNS0-Anfragen richtig funktioniert. Hinweise für eine nicht richtig funktionierende EDNS0-Anfrage liefert eine BIND9-Meldung wie z.B.:

too many timeouts resolving 'ze.akamaitech.net/AAAA' (in 'akamaitech.net'?): disabling EDNS

EDNS0-Anfragen passen oft nicht in die (alten) UDP-Pakete mit einer Länge von 512 Bytes. Mit

dig +norec +dnssec example.com @a.root-servers.net

kann getestet werden, ob die Firewall UDP-Pakete mit einer Länge größer als 512 Bytes durchlässt. Mit

dig +dnssec +norec +ignore dnskey se @A.NS.se

kann getestet werden, ob IP Fragmente für UDP unterstützt werden.