DNS

• Stub Resolver

• Forwarder

• Recursive Resolver

• Authorative Name Server

• TLD name server

• Root Server

• Provides recursive resolution for a system which lacks resources (e.g. your PC)

• Forwards DNS queries to another resolver

• E.g. your routers resolver

• Handles recursive queries and iteratively resolves them

• Usually open resolvers are recursive resolver

• Has authoritative information on a set of zones

• Gets queried by recursive resolvers

• Authoritative nameserver for the TLD zones

• E.g. a.nic.de for the de zone

• Authoritative name servers which serve the DNS root zone1

• 13 authorities manage hundreds of servers: [a-m].root-servers.net

• E.g. k.root- servers.net is managed by RIPE

• https://root-servers.org/ tracks the location of many root servers

• System to resolve Fully Qualified Domain Name (FQDN) to IP addresses

• Original concept focused on high scalability → distributed database

• Header

• Question (question of NS)

• Answer (RR answering the question)

• Authority (RR pointing toward an authority)

• Additinoal (RR holding additional information)

• Query and Response use same format

• Header indicates type of message

• Answer, authority and additional section are arrays of RR

• ID -> Unique query ID to identify the corresponding response

• QR -> Set if the message is a response (FLAG)

• Opcode -> Specifies kind of query (e.g. query, status, notify, update)

• AA: Authorative Answer -> Set if the responding name server is an authority for the requested domain (FLAG)

• TC: Truncated -> Indicates that the DNS message is truncated due to the permitted length (FLAG)

• RD: Recursion desired -> If set the nameserver resolves the query recursivley (FLAG)

• RA: Recursion available -> Set by the nameserver if it supports recursive queries (FLAG)

• Z -> 1 bit future use; 2 bits for DNSSEC (authentic data (AD) and checking disabled (CD))

• RCODE: Response code -> Code indicating query errors (e.g. NOERROR, NXDOMAIN, SERVFAIL)

• (QD,AN,NS,AR)*COUNT -> Number of RR in the corresponding message section

• QNAME -> Requested Name, var. length

• QTYPE -> Requested RR type (e.g. A, NS)

• QCLASS -> Normally Internet (IN)

• Name

• Type

• Class

• TTL

• RDLENGTH -> length of the following data

• RATA -> data of the RR mapped to the name

• A -> IPv4 host address as 32 bit address

• AAAA -> IPv6 host address as 128 bit address

• CNAME -> canonical name for an alias -> a domain name

• NS -> Authorative Name Server -> domain name

• SOA -> Start of zone authority (various fields)

• MX -> mail exchange record -> preference and mail server domain name

• TXT -> TXT record -> arbitratry text

• SVCB -> service binding record -> informainto on services

• HTTPS -> HTTPS service binding record -> informatino on the HTTPS service

• authorative information that is organized into units

• -> can be automatically distributed to name servers which provide redundant service for the data in a zone

• set of name server records (authorative name servers)

• starts with SOA record ends at next SOA record

• Can have child and parent zone

• Can do delegation

• entity on record that has the delegation of the domain from the parent

• domain in which the child is regstered

• creating a separate zone in the name space benenath the apex of a given domain

• => Basically, SOA tum.de delegates authority for in.tum.de to another authoratice name server…

• delegation indicated with NS record -> points to domain name (and then should also have record pointing to that domain anme…)

• delegation to NS in own zone -> e.g. delegate net.in.tum.de to nsi.tum.de

• required to retrieve A/AAAA record of in-bailiwick records

• -> have NS entry with domain of authorative name server

• also have A or AAAA record entry for this domain name ot allow the continuing of resolving…

• => A/AAAA record in parent zone for name server of a child zone

• -> non authroative records in the parent zone

• nodes with children but no RR of their own

• => return NOERROR but RR in answer section if queried

• important for QNAME minimizatoin and rDNS walking

• NS record points to IP address

  • not reachable and not valid

  • reliability issues (e.g. other name server not reachable / overloaded)

• NS record contains typo in domain name

  • 1. domain name not registrable

    • reliablity issue

  • domain name is open registrable

    • -> Hijacking possibility

• NS record points to host without DNS service or without authorative information on the zone (lame delegation)

  
  

• A set of all components critical to a systems security

• First defined in the context of the kernel and trusted processes by John Rushby

• Ramasubramanian et al. defines: The nameservers in the delegation graph of a domain name form the trusted computing base(TCB) of that name.

• More general: A zones TCB consists of all zones in the delegation graph

• tum.de

• -> .de

• -> . (root zone)

• tum.de has NS in dns1.lrz.de; dns2.lrz.bayern.; dns3.lrz.eu.

• => lrz.de

• => lrz.bayern.

• => bayern.

• => lrz.eu

• => eu.

=> are all in TCB…

• last part of domain that are shared between multiple sites from different owners

• - e.g. co.uk,…

etld+1

• same, but with same owner…

• google.com (-> www.google.com, drive.google.com,…)

• etld+1 gives idea of number of parties involved

• -> more parties higher attack surface

• => lower is better…

• provide redundancy…

• -> placed bith topologically and geographically dispresed locations on internet

• -> to minimize likelihood of single failure disabling all of them…

• UDP is default

• but fallback to TCP

• DNS UDP support up to 512 byte payload

• -> with addition such as DNSSEC and EDNS0 the boundary of 512 bytes is easily broken

• UDP fragmentation does not work reliiable

• -> when it works, can be abused…

• Extension mechanism for DNS

• allows DNS messages to have bigger size

Features:

• Backward compatible

• advertises size of max UDP payload size

• extend 4 bit RCODE

• adds new label types

• adds the OPT pseudo-RR

• EDNS Client Subnet (ECS)

• -> Resolver forwards client IP addres to the authorative name server…

• sends:

  • IP address family

  • source prefix length (number of relevant bits in the IP address)

  • scope prefix length (number of bits the response covers)

  • IP address

• Recursive resolvers can simply forward ECS requests

  • useful for architectures including forwarders

• caching policy

  • source prefix length denotes maximum cachable

  • source rpefix length > scope prefix length

    • less bits needed for best response

Maybe have a better look at this topic elsewhere….

• scalability and distribution

• no authentication of replsse

• integrity of replies not protected

• client privacy not given

  • queries sent in plaintext

  • queries reveal information about client behavior / traffic

• DNSEC

• DNS Encryption

• QNAME Minimization

• provide authenticity and integrity of DNS responses

  
  

• protect the privacy of a client

• encrypt the traffic between client and resolver

• e.g. DNS over TLS (DoT), DNS over HTTPS

• protect the privacy of a client

• reduce the information sent to nameservers

• sign DNS records

  • Public-key cryptography

  • Verified public keys of the DNS root zone (Trusted Third Party)

  • Authentication chain of trust from root zone to child zone

• Additional DNS RRs to integrate DNSSEC, e.g.,

  • RRSIG (Resource Record Signature)

  • DNSKEY (Public Key)

  • NSEC/NSEC3 (Next secure record (v3))

Problem Statement:

• Queries in plain text reveal user behavior and accessed services

• Nearly everything in the Internet relies on DNS

• Intercepting client traffic enables detailed fingerprinting

• DNS encryption only targets the communication between client and resolver

• Recursive queries from resolver to name servers are still plain text

• These queries should not contain client information

• DNS resolution itself is not altered

• Resolvers can be trusted

• Resolvers are used by a large number of clients

• DNSCrypt

• DNS over TLS

• DNS over HTTPS

• Own protocol for encryption and authentication

• Supports UDP and TCP with port 443

• Uses existing protocol TLS for encryption

• Based on TCP instead of UDP

• Uses port 853 (Critics: can be blocked)

• Uses HTTPS for communication and encryption

• Based on TCP instead of UDP

• Uses port 443 (hard to block)

• Can be configured individually by applications in user space

Pros:

• Client traffic is encrypted Cons:

• Internal DNS configurations might be overwritten

Debatable:

• DoH/DoT is faster? •

  • TLS/HTTPS is fast and well studied but DNS (UDP/53) as well

• DoH/DoT prevents censorship?

  • The behavior of a resolver is unchanged

  • Probably more clients use large, international resolvers in the future

  • But they can censor as well or might be forced to by governments

• DoH/DoT prevents collection of your data?

  • Data can still be collected by the resolver

• You still have to trust the resolver

• Data can still be collected

• Censorship is still possible

• Only eavesdropping traffic is limited

• Resolvers initially sent the complete QNAME and requested QTYPE to all name servers

• Each name server during the recursive resolution learns about the QNAME and QTYPE

• DNS Query Name Minimisation RFC7816 [5]

• Send the exact QNAME and QTYPE only to the authoritative NS

• Only resolve the authoritative NS for each label during the recursive resolution

• want to resolve asciiart.grnvs.net.

• first resolve net.

• at the authorative NS of net., resolve grnvs.net.

• at the next asciiart.grnvs.net. …

  
  

• Increased rate of unsuccessful queries (up to 5%[6])

  • Some NS incorrectly reply to NS queries (REFUSED)

  • → Use different QTYPE (A, AAAA)

  • Some NS incorrectly reply to emtpy labels (no data for name)

  • → Fallback to query with all labels •

• Increased query load (up to 26% [6])

  • All labels have to be queried one by one

  • A NS authoritative for multiple labels could reply with most significant reply if full name is known

  • → Fallback to query with all labels when same NS is queried

• →  Deployment of QNAME minimization is hindered by NS miss-configurations

• →  Resolver implement algorithms with different fallback behavior