Support SOA record type

[pczarn]

Example

{
    "google.com" : [
        {
            "rdata": "62.252.169.178"
        },
        {
            "rtype" : "SOA",
            "rdata": {
                "mname": "ns.google.com",
                "rname": "dns-admin.google.com",
                "serial": 2003080800,
                "refresh": 172800,
                "expire": 1209600,
                "retry": 900,
                "minimum": 3600
            }
        }
    ]
}

Implements #37

[MaddieM4]

There's some breakage in the Travis testing, but it looks to be all legacy stuff that's my fault. It's stuff I remember fixing, though, so I suspect it's stuff I did in another branch and never got around to merging in. I'll see if I can fix master on my side, which you can then merge in to get the fixes (shouldn't interfere with your code).

[MaddieM4]

Okay, master is fixed in my repo. Merge that into your branch, and we'll see what test failures are left.

[MaddieM4]

Oh, and this also deserves a test in pymads/tests/test_resolution.py. There are plenty of good examples in there - the most pertinent to recursive-resolution-from-external-server would be test_CNAME (frozen response packet captured via Wireshark), but for testing SOAs defined in JSON, test_A and test_AAAA are better models. Up to you what you want to focus on, though IMHO, the best solution is to go with the frozen packet model, and then optionally cover the JSON use case in test_chain.py as part of test_jsonsource().

[pczarn]

Sure, I was going to take a look at tests.

I don't think this change deserves the use case in JSON. There's nothing outstanding in parsing a dict as rdata field.

But test_cycle_response needs to be expanded.

[MaddieM4]

Good catch. Sounds like you're on top of it, so I'll leave you to it :)

On Thu, Aug 15, 2013 at 3:01 AM, Piotr notifications@github.com wrote:

Sure, I was going to take a look at tests.

I don't think this change deserves the use case in JSON. There's nothing outstanding in parsing a dict as rdata field.

But test_cycle_response needs to be expanded.

— Reply to this email directly or view it on GitHubhttps://github.com/campadrenalin/pymads/pull/38#issuecomment-22694581 .

[pczarn]

Thank you. That's all, right? By the way, how to resolve ICANN AAAA records with SOA? Using provided name servers?

That's how I got response without Wireshark

from pymads.sources.dns import DnsSource
from pymads.request import Request
req_in = Request(1, ['www', 'theuselessweb', 'com'], 'SOA')
dns = DnsSource()
req_out = dns._make_request(req_in.name, req_in.qtype, req_in.qclass)
>>> dns._exchange_data(req_out.pack())
RawData((0x0,0x1,0x81,0x80,0x0,0x1,0x0,0x3,0x0,0x0,0x0,0x0,0x3,0x77,0x77,0x77,0xd,0x74,0x68,0x65,0x75,0x73,0x65,0x6c,0x65,0x73,0x73,0x77,0x65,0x62,0x3,0x63,0x6f,0x6d,0x0,0x0,0x6,0x0,0x1,0xc0,0xc,0x0,0x5,0x0,0x1,0x0,0x0,0xe,0x10,0x0,0x37,0x3,0x77,0x77,0x77,0xd,0x74,0x68,0x65,0x75,0x73,0x65,0x6c,0x65,0x73,0x73,0x77,0x65,0x62,0x3,0x63,0x6f,0x6d,0x14,0x73,0x33,0x2d,0x77,0x65,0x62,0x73,0x69,0x74,0x65,0x2d,0x75,0x73,0x2d,0x65,0x61,0x73,0x74,0x2d,0x31,0x9,0x61,0x6d,0x61,0x7a,0x6f,0x6e,0x61,0x77,0x73,0xc0,0x1e,0xc0,0x33,0x0,0x5,0x0,0x1,0x0,0x0,0x0,0x3c,0x0,0x2,0xc0,0x49,0xc0,0x49,0x0,0x6,0x0,0x1,0x0,0x0,0x3,0x84,0x0,0x48,0x7,0x6e,0x73,0x2d,0x31,0x39,0x31,0x39,0x9,0x61,0x77,0x73,0x64,0x6e,0x73,0x2d,0x34,0x37,0x2,0x63,0x6f,0x2,0x75,0x6b,0x0,0x11,0x61,0x77,0x73,0x64,0x6e,0x73,0x2d,0x68,0x6f,0x73,0x74,0x6d,0x61,0x73,0x74,0x65,0x72,0x6,0x61,0x6d,0x61,0x7a,0x6f,0x6e,0xc0,0x1e,0x0,0x0,0x0,0x1,0x0,0x0,0x1c,0x20,0x0,0x0,0x3,0x84,0x0,0x12,0x75,0x0,0x0,0x1,0x51,0x80))

[MaddieM4]

Thank you. That's all, right?

Pretty sure. Although I'm not sure if www.theuselessweb.com has useful SOA records. Probably better to use uppit.us.

By the way, how to resolve ICANN AAAA records with SOA? Using provided name servers?

As I understand it, that's handled at other layers of the stack. Not sure if it's application-level or kernel-level, but resolution should just send an additional request when it gets an SOA result. I've been taking this for granted, but I'll do a Wireshark test later on to be absolutely sure.

That's how I got response without Wireshark

Very clever! I broke out dns._make_request and dns._exchange_data for exactly this purpose, awhile ago, and then kinda forgot about it earlier when I recommended using Wireshark. I'm impressed that you managed to figure it out on your own, despite me being useless in the endeavor. But yeah, your code there uses things as they were intended to be used, and that should work just fine.

[pczarn]

Any SOA record should be enough for a test.

Not that hard to figure out the code

1. DummyDnsSource is initialized with RawData and implements only _exchange_data that returns it
2. DnsSource._exchange_data behaves similarly, so DummyDnsSource(dns._exchange_data) will work
3. DnsSource uses remote server
4. _exchange_data is called from exchange

[MaddieM4]

Ah, I ran dig -t SOA www.theuselessweb.com earlier, and didn't get any SOA records in the results, so that was the cause of my concern. However, when I thought to actually run it with server specified, to be the same as the one that DnsSource queries (dig -t SOA www.theuselessweb.com @8.8.8.8), the results did in fact contain an SOA record after all. So yeah, you should be good.