(All) DNS Resource Records | Hacker News Reader

(All) DNS Resource Records

netmeister.org

122 pointszdw19 comments

The DNS zone text file format is the most horrific, loosely specified thing to parse

I did some experiments a number of years ago and found almost none of the DNS server software out there parses zone files the same, particularly surrounding parenthesis, line wrapping, and unknown record types.

I discovered this when I wrote a Vim function to automatically update the serial of the SOA record (can be easy to forget if in a hurry) whenever I saved a zone file. It worked fine for my own zone files, similar to:

    $ORIGIN example.com.
    @  IN  SOA  ns.example.info.  hostmaster.example.info. (
     2021031306  ; Serial
            12h  ; Refresh (secondary server accepts zone update notifications)
             2h  ; Retry (how long secondary should wait before retrying)
            14d  ; Expire (how long records should be considered valid by secondary)
             1h  ; NXDOMAIN (Nonexistent domain) TTL – previously the Minimum TTL
        )

I considered publishing my Vim script but figured I should improve it so that it would work for all valid zone files. Then I read the Master Files section of RFC 1035¹ and realised that this would be more difficult than I had assumed. I’m also not particularly proficient with Vimscript so I never published it. Since then, I’ve converted my zones to be dynamic so I don’t need to worry about formatting or updating the serial.

Out of interest, which name server had the most robust parsing of zone files?

1. https://tools.ietf.org/html/rfc1035#section-5

Robustness is irrelevant, because whenever there is a hole in the various specs people ask "What is BIND doing?"

It's sad SRV records are not used for the web for running http(s) services on different ports (instead of virtual hosts and SNI).

And because SRV records are not used for the web, they can't be used at all, as some routers or something doesn't support them and instead discards them. (~10% of users according to the admin of yaxim.org)

And then along comes https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... defining a "SRV2", SVCB and also its identical twin the HTTPS RR (same format, different RR number). I have a fear that those routers will end up supporting the HTTPS RR but not SVCB...

I've never had problems with srv records for matrix servers, Minecraft servers, email auto configuration etc.

The draft outlines the differences from SRV for anyone curious:

* https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-...

Outside of businesses it doesn't matter at all. You'll use DoH to escape local garbage. A variation on Happy Eyeballs will automatically try to do QUIC unless that doesn't work in which case you get TLS.

At work, obviously IT group policy, "security" middle boxes and so on will insist on whatever set of nonsense is just barely enough to keep the Marketing Director's twitter working how she likes it, and the Sales Director's Candy Crush on his work phone. Can't help you really on that.

SRV records are critical for the functionality of SIP and VoIP.

The lack of adoption of SRV records for web protocols fills me with immense sadness. Having a separate service location layer, as a general design principle, would have made so many things much easier on the Internet (load balancing, failover, multiplexing multiple services on a single IP).

Then you'll love HTTPS records, described at the linked article and currently being finished up for use with QUIC and ECH.

If HTTP(S) would run on a multitude of ports in the wild, firewalling would become an impossible task.

IPv6 also solves the problem, as you can easily assign a big subnet to a web server and one IP per (sub-) domain.

And with the upcoming ESNI there are probably some additional privacy benefits.

But - if we had SRV records for http(s), things like geo load balancing would be super simple, no need for anycast / weird CNAME chains. The client would get a list of hosts, with attached priorities, and weights.

Do you have any further information on this topic, some blog post or something that explains how this would work?

I don't have a specific URL for you (other than for the authoritative source, the DNS RFCs) but a good example would be how clients in an Active Directory environment find a Domain Controller to log on to -- I'm sure there's plenty of documentation and examples of that on the web!

Hint: This same method (SRV RRs and priorities/weights) so that a client communicates with a Domain Controller down the hall, instead of another one halfway across the country.

Then, just imagine that it's a web browser connecting to a web server, instead of a workstation connecting to a DC.

basically normal A response (whether or not coming from a cname) doesn't define any weights or priority. just order may be changed by the server

according to clients' geoip, you just need to adjust weights/priority in the srv record so, a client can fallback next-nearest server

Why is that sad?

Why are we not all using

  sshfp

records? They seem quite useful even without dnssec. Or is the lack of dnssec the only reason they’re not/little used?

Because SSH certificates are a more powerful solution to the problem, work effectively in both directions, support short-lived keys linked to MFA, and are supported by a lot of tooling that SSHFP doesn't have. SSHFP is dead.

Reply on news.ycombinator.com