HN Explorer

31 comments

[ 3.6 ms ] story [ 79.9 ms ] thread
dijit
So, they don't use IP Telephony then?

You're aware you can add whatever you want into DNS, it doesn't have to mean anything that computers understand right? you /could/ make your A records the intro to Star Wars- but nobody will be able to use your site.

TXT is a much better option imho, or.. y'know, not doing this.

orik
Well I guess I need a new alt. dns to provision phones with.
legind
TXT isn't an option because the records themselves are unsorted. Use the above command without the pipe to sort looks weird, but not as weird as TXT would.
dijit
MX or with numbers then?
LukeShu
TXT records are actually variably-sized arrays of strings, making them very suitable for ASCII art. Unfortunately, `dig +short TXT` displays them as

    "string1" "string2" "string3"
instead of on separate lines. However, this is easily remedied with sed.

Using TXT for artwork also has the advantage that you don't risk an intermediate resolver re-ordering things.

Source: When this came up about a month ago: https://news.ycombinator.com/item?id=7185326

[deleted]
(comment deleted)
ten7
I really don't think you need to use NAPTR here. Using TXT works just fine, if you do a sort, if you prepend line numbers to the records. Alas, you still have to do a sort. It would be wonderful if there was a hack that involved not using the sort. Here's one I just added: dig txt art.ten7.com |sort
Patrick_Devine
Unfortunately our DNS service doesn't allow NAPTR records, so we had to go the TXT route. Here's a large wooden object:

dig +short txt log.netkine.com | sed $'s/\" \"/\\\n/g'

anon4
I get this. I can't make out what it's supposed to be.

                         P!**9N#
                        9=  #(a:?4
                       {w   Tj(d w?#
                     @(d   !nPx   A>4
                    P=W  @{d :   9=w\;
                   V:   9a# td P:d  tj
                  {w  9=W# Px @=#  F=+
                @(d  {d  #@= P=   P=@:
               P=#  WJ#sjP:WP= a?tx(a#
              P=@=d  gawV= 9=     wawa\;?
             {w :    #9:w       @!9_axw
           @{d 1d P9:wd    P9na\;=# WSgmN
          P=W @=9=w    9{  # #:w   W4Wmm
         Pn  #(vj   P{aW    #{d     W4Dm
        !a P9nW    !w#     P:d        mW
      #{d@:w##    {d9:/4  P=
     P=WP=@=w/#  Px{J4Pd {a
    P\;H1w Aw9j#  :m?(J:W{d
   Ynwwaa*:wW## {d  9=V:d
   \;44#WWRav*# tj 9:d@=
   A?WW#W#W#w==d@(d !a
    A?WWUWQ#mNs4:W td
     As*XUW#UWNsj@:d
      #wv!W4W WW?=#
         bw?9*9!="
dspig
a log...
adefa
it's big, it's heavy, it's wood
voltagex_
Which clients use NAPTR? Can't you have a SRV record without NAPTR?
MichaelGG
>So, they don't use IP Telephony then?

A lot of VoIP deployments simply ignore the whole DNS side of things, or at best use an A record. Especially in wholesale, it's IP only (using domains breaks some things), and authentication is based on IP, too. (Source IP on a UDP packet - very secure.)

EricBurnett
My first thought on seeing that is it would be great for a DNS amplification attack. Not sure the value as an advertisement though...
dijit
I think it's too big for UDP, it'll renegotiate TCP for anything over a certain size.

thus DNS amplification is impossible because spoofing the TCP source would fail a handshake.

dice
The size is 1876 bytes, DNS servers which support EDNS will do up to 4096 byte replies in UDP.
djcornell
agreed, this is a bad idea and is likely to be abused shortly
m_ram
Here's the whole thing unsorted: http://pastebin.com/z7BzEnhC

and in case you want to learn about NAPTR: http://www.ietf.org/rfc/rfc2915.txt

userbinator
Regular expressions in DNS records? That sounds like it would be an easy possibility of exponential resource consumption: http://en.wikipedia.org/wiki/ReDoS

After a quick Google, it turns out some versions of ISC BIND were vulnerable to this... but I'm almost willing to bet a lot of other software that handles NAPTR could be as well.

coreymgilmore
looks like someone had a little too much time on their hands...

great work though

i31415
Not the only ones:

  dig ch whois.cloudflare @lee.ns.cloudflare.com
Note its TCP only to prevent abuse. Also overloading the Chaos protocol to avoid messing with real DNS.
[deleted]
(comment deleted)
acd
What happens if someone chops up binary data such as a copyright movie file BASE64 encoded into DNS text records? Does all the DNS operators with that in the cache become illegal file sharers then?
simias
Not binary data but: http://decss.zoy.org/

Loot at entry 9, they use a similar hack to distribute the DeCSS (DVD DRM decryption program) source code through DNS.

> Mark Baker noticed that you could do the request to any nameserver. Which means for instance that the DeCSS source code is available from the DVDCCA's nameservers !

notfoss
Interestingly, with OpenDNS, this does not show up using the any query:

    $ dig @208.67.222.222 any eff.org

    ; <<>> DiG 9.9.2-P2 <<>> @208.67.222.222 any eff.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61530
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;eff.org.                       IN      ANY

    ;; ANSWER SECTION:
    eff.org.                3756    IN      A       69.50.225.155
    eff.org.                6413    IN      NS      ns6.eff.org.
    eff.org.                6413    IN      NS      ns2.eff.org.
    eff.org.                6413    IN      NS      ns1.eff.org.
    eff.org.                507     IN      SOA     ns1.eff.org. hostmaster.eff.org. 2014031300 3600 1800 604800 1800

    ;; Query time: 380 msec
    ;; SERVER: 208.67.222.222#53(208.67.222.222)
    ;; WHEN: Fri Mar 14 22:26:33 2014
    ;; MSG SIZE  rcvd: 153
Though, explicitly specifying the NAPTR type does display it:

    $ dig @208.67.222.222 -t naptr eff.org

    ; <<>> DiG 9.9.2-P2 <<>> @208.67.222.222 -t naptr eff.org
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65029
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 23, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;eff.org.                       IN      NAPTR

    ;; ANSWER SECTION:
    eff.org.                6304    IN      NAPTR   300 10 "" "                 !!!!!!!!!!!!!!!!!!!!!!!!!!                 " "" .
    eff.org.                6304    IN      NAPTR   310 10 "" "                     !!!!!!!!!!!!!!!!!!                     " "" .
    eff.org.                6304    IN      NAPTR   320 10 "" "                         !!!!!!!!!!!                        " "" .
    eff.org.                6304    IN      NAPTR   100 10 "" "                          !!!!!!!!!                         " "" .
    eff.org.                6304    IN      NAPTR   110 10 "" "                      !!!!!!!!!!!!!!!!!!                    " "" .
    eff.org.                6304    IN      NAPTR   120 10 "" "                   !!!!!!!!!!!!!!!!!!!!!!!!                 " "" .
    eff.org.                6304    IN      NAPTR   130 10 "" "                !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!              " "" .
    eff.org.                6304    IN      NAPTR   140 10 "" "              !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!            " "" .
    eff.org.                6304    IN      NAPTR   150 10 "" "            !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!          " "" .
    eff.org.                6304    IN      NAPTR   160 10 "" "     @@@@@@@@@@@@@@@@@@!!!!!!!!!     !!!!!!!!!!!!!!         " "" .
    eff.org.                6304    IN      NAPTR   170 10 "" "     @@@@@@@@@@@@@@@@@@!!!!!!!!!  !!!!!!!!!!!!!!!!!!        " "" .
    eff.org.                6304    IN      NAPTR   180 10 "" "     @@@@@@@!!!!!!!!!!!!!!!!!!!!    !!!!!!!!!!!!!!!!        " "" .
    eff.org.                6304    IN      NAPTR   190 10 "" "     @@@@@@@!!!!!!!!!!!!!!!!!!!!  !!!!!!!!!!!!!!!!!!!       " "" .
    eff.org.                6304    IN      NAPTR   200 10 "" "     @@@@@@@!!!!!!!!!!!!!!!!!!!!  !!!!!!!!!!!!!!!!!!!       " "" .
    eff.org.                6304    IN      NAPTR   210 10 "" "     @@@@@@@@@@@@@@@@@@!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!...